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ABSTRACT 


The  Standards  Analysis,  Synthesis,  and  Expression  (SASE)  methodology 
provides  an  objective  and  rigorous  representation  of  the  content  and 
organization  of  a standard.  Both  the  methodology  and  a computer  program 
that  implements  it  are  described  in  this  document  in  terms  of  two 
underlying  conceptual  models.  The  conceptual  model  for  the  information 
content  of  a standard  is  essentially  independent  of  any  particular 
organization  and  expression  of  the  information.  The  fundamental  unit  of 
information  in  the  model  is  a provision  stipulating  that  a product  or 
process  have  some  quality.  The  highest  level  provisions  in  a standard  are 
requirements  that  directly  indicate  compliance  with  some  portion  of  the 
standard  and  are  either  satisfied  or  violated.  Techniques  are  provided  in 
SASE  to  ensure  that  individual  provisions  are  unique,  complete,  and 
correct,  and  that  the  relations  between  provisions  .are  connected,  acyclic, 
and  consistent.  Entities  in  SASE  that  represent  the  information  content  of 
a standard  are  data  items,  decision  tables,  decision  trees,  functions,  and 
information  networks.  The  conceptual  model  for  the  organization  of  a 
standard  is  based  on  a logical  classification  system  in  which  each 
requirement  is  classed  in  terms  of  its  subject  (product  or  process)  and 
predicate  (required  quality) . Techniques  are  provided  in  SASE  for  building 
and  manipulating  hierarchical  trees  of  classifiers  and  testing  the 
resulting  organization  for  completeness  and  clarity.  Entities  in  SASE  that 
deal  with  the  organization  of  a standard  are  classifiers,  hierarchy, 
scopelist,  index,  organization,  and  outline.  The  SASE  methodology  is 
demonstrated  in  an  analysis  of  a complete  standard  for  concrete  quality.  An 
annotated  bibliography  of  the  most  significant  relevant  research  reports  is 
presented. 

keywords:  Arrangement,  building,  classification,  code,  consistency, 
knowledge  representation,  organization,  provisions,  standards 


iii 


FOREWORD 


This  report  is  intended  to  serve  two  purposes ; 

• To  provide  an  introduction  to  the  methodology  of  Standards 
Analysis,  Synthesis,  and  Expression  (SASE)  by  summarizing  in  one 
place  the  concepts  and  methods  developed  over  nearly  two  decades; 
and 

« To  serve  as  a tutorial  guide  to  the  SASE  program  which  implements 
that  methodology. 

A chronological  annotated  bibliography  of  the  publications  leading  up  to 
this  report  is  presented  in  Appendix  B.  The  documentation  of  the  SASE 
program  is  contained  in  the  companion  SASE  User  Manual'^. 

The  writers  appreciate  the  contributions  of  several  colleagues.  Judy 
Calabrese  and  Charles  Yancey  assisted  with  the  study  described  in  Appendix 
A.  James  Harris  made  a considerable  contribution  to  the  design  of  the  SASE 
software  and  the  planning  of  this  study,  and  was  lead  author  of  the 
principal  resource  document.  Steven  Bushby  provided  numerous  insightful 
comments  in  his  critical  review  of  the  manuscript.  Systems  Architects,  Inc. 
of  Falls  Church,  Virginia,  prepared  the  initial  version  of  the  SASE 
program. 
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NBSIR  87-3514.  See  reference  4 of  this  report. 
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1.  INTRODUCTION 


The  Standards  Analysis,  Synthesis,  and  Expression  (SASE)  methodology  pro- 
vides an  objective  and  rigorous  representation  of  the  meaning  of  a stan- 
dard. It  is  intended  to  assist  organizations  engaged  in  the  formulation, 
promulgation,  and  maintenance  of  standards.  In  order  to  put  SASE  in  con- 
text, this  chapter  presents  first  a discussion  of  standards  followed  by  a 
discussion  of  the  role  of  SASE.  Finally,  the  organization  of  this  document 
is  discussed. 

1 . 1 Standards 

In  this  discussion,  the  term  standard  includes  all  types  of  normative 
documents  used  to  define  the  required  qualities  of  buildings,  building 
products,  materials,  or  building  processes.  The  term  includes  legal  build- 
ing regulations , consensus  standards  such  as  those  of  the  American  National 
Standards  Institute  and  of  the  International  Organization  for  Standardiza- 
tion, and  proprietary  specifications.  Standards  are  used  for  communication 
between  buyer  and  seller  and  for  protection  of  public  health,  safety,  and 
welfare . 

Standards  from  many  technology  areas  should  be  equally  amenable  to  the  SASE 
methodology.  However,  the  methodology  and  the  information  models  on  which 
it  is  based  have  been  tested  extensively  only  in  areas  of  building  technol- 
ogy- 

1.1.1  The  Standards  Development  Process 

Standards  are  generally  developed  following  the  principle  of  due  process  in 
notification,  balloting,  resolution  of  dissent,  and  careful  record  keeping. 
A standard  is  usually  drafted  by  a committee  of  experts  who: 

• define  the  scope,  including  the  products  or  processes  to  be  covered 
and  their  required  performance  attributes; 

• determine  whether  to  express  the  standard  as  a performance  standard 
(attributes  in  terms  of  user  needs  [19]),  procedural  standard 
(attributes  in  terms  of  specified,  rigorous  technical  evaluation 
procedures  [5]),  or  prescriptive  standard  (attributes  given  as 
dimensions  or  properties  completely  defining  the  acceptable  con- 
figuration or  procedures) ; 

• formulate  the  standard,  that  is,  develop  appropriate  provisions  for 
ascertaining  that  the  required  performance  attributes  of  the  prod- 
ucts or  processes  are  satisfied;  and 

• submit  the  draft  standard  to  the  organization  responsible  for 
promulgation  and  maintenance. 

The  process  of  promulgation  and  maintenance  is  typically  of  long  duration. 
Modifications  and  interpretations  may  occur  without  participation  of  or 
consultation  with  the  experts  who  initially  drafted  the  standard. 
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1.1.2  Shortcomings  of  the  Process 

A number  of  problems  arise  in  the  present  process  of  developing  standards. 
First,  the  process  itself  is  expensive  because  much  time  and  effort  is 
required  from  leading  experts  in  the  subject  area  and  from  those  whose 
interests  are  affected.  Most  of  this  time  and  effort  is  expended  in  mutu- 
ally understanding  technical  issues  and  resolving  them. 

Second,  the  slowness  of  the  process  means  that  standards  may  become  obso- 
lete or  even  technically  incorrect  and  continue  to  be  used  for  some  time 
while  new  or  modified  standards  are  being  developed.  This  problem  is  exac- 
erbated by  rapidly  changing  societal  demands  for  building  qualities,  such 
as  energy  conservation,  and  rapidly  changing  technologies  in  building 
products  and  processes,  both  of  which  lead  to  many  new  subjects  for  stand- 
ardization and  the  frequent  revision  of  existing  standards. 

Third,  once  a standard  is  developed,  each  user  of  the  standard  must  invest 
time  and  effort  in  interpreting  it,  that  is: 

• locating  all  relevant  provisions;  and 

• understanding  and  correctly  applying  the  applicable  provisions. 

Ultimately,  society  bears  the  additional  risks  and  expenses  that  arise  from 
the  potential  building  malfunctions  and  waste  associated  with  the  use  of 
obsolete,  incorrect,  or  incorrectly  applied  standards. 

The  increased  use  of  computer-aided  design  potentially  magnifies  these 
problems.  A single  error  in  interpretation  of  a standard  by  the  developer 
of  a computer  program  may  lead  to  many  errors  in  application  as  the  program 
is  used.  Furthermore,  the  time  and  expense  associated  with  updating  pro- 
grams to  incorporate  revisions  in  standards  cause  programs  to  lag  behind 
and  to  act  as  impediments  to  the  application  of  improved  technologies  that 
can  increase  the  economy,  safety,  or  usefulness  of  buildings. 

An  objective,  analytical  method  for  generating  and  reviewing  either  the 
content  or  the  form  of  a proposed  new  standard  or  modifications  of  an 
existing  one  would  help  mitigate  the  problems  described  above  by  providing 
experts  and  users  both  with  explicit  representations  of  the  content  and 
organization  of  the  standard.  Because  standards  are  so  important  to  indus- 
try and  because  the  cost  of  producing  them  is  high,  there  is  a need  for 
such  a method,  beyond  due  process,  informal  peer  review,  and  occasional 
test  comparisons  with  previous  standards,  for  making  objective  evaluations 
of  the  logic  and  internal  consistency  of  standards.  The  SASE  methodology 
fills  this  need. 

1 . 2 Role  of  SASE  in  the  Standards  Development  Process 

The  methodology  embodied  in  SASE  deals  exclusively  with  the  logic,  format, 
and  organization  of  standards,  that  is,  their  syntax.  Because  of  this 
emphasis  on  syntax,  SASE  is  applicable  to  the  entire  range  of  standards 
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discussed  in  section  1.1.  By  contrast,  the  meaning  or  semantics  of  each 
standard  is  highly  specific  to  its  subject  area,  and  requires  the  back- 
ground and  knowledge  of  experts  in  the  area  for  proper  analysis  and  synthe- 
sis . 

The  objective  of  SASE  is  to  provide  a formal  methodology  to  represent  the 
logic  and  organization  of  standards  so  as  to  ensure  the  following  qualities 
in  a standard: 

1.  Individual  provisions  need  to  be: 

• Unique  - the  provision  must  yield  one  and  only  result  in  any 
possible  application; 

• Complete  - the  provision  must  apply  explicitly  to  all  possible 
situations;  and 

• Correct  - the  result  of  applying  the  provision  is  to  be  consis- 
tent with  the  objective  of  the  standard. 

2.  Relations  among  provisions  should  be: 

• Connected  - explicit  cross  references  must  show  the  data  re- 
quired for  the  application  of  each  provision  and  the  use  stipu- 
lated for  the  data  produced  by  each  provision. 

• Acyclic  - the  data  produced  by  evaluation  of  a provision  should 
not  be  required  prior  to  its  evaluation  (no  loops  in  logic)  ; 
and 

• Consistent  - uniform  logical  and  technical  bases  must  be  pro- 
vided for  comparable  provisions. 

3.  The  organization  of  the  standard  should  be: 

• Complete  - explicit  scope  must  be  provided  so  that  a user  knows 
the  subjects  and  qualities  covered  by  the  standard;  and 

• Clear  - the  arrangement  and  display  of  provisions  should  be 
such  that  the  user  readily  finds  all  provisions  pertinent  to 
his  query. 

1.2.1  The  Application  of  SASE 

The  methodology  of  SASE  is  applicable  to  three  distinct  processes  in  stan- 
dards development. 

1.  Analysis  - the  process  of  extracting  the  information  content  of  an 

existing  standard.  This  is  the  necessary  first  step  in  modifying 

or  updating  an  existing  standard. 
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2. 


S3mthesis  - the  process  of  generating  the  information  content  of  a 
new  or  modified  standard.  This  process  is  most  directly  concerned 
with  ensuring  that  the  standard  possesses  the  qualities  presented 
previously . 

3.  Expression  - the  process  of  expressing  the  previously  synthesized 
information  content  in  textual  form. 

The  first  two  processes  are  collectively  referred  to  as  the  formulation  of 
a standard  since  they  lead  to  the  format  and  complete  representation  of  the 
information  content. 

1.2.2  Mode  of  usage  of  SASE 

SASE  may  be  used  in  the  development  of  a standard  by  designating  one  or 
more  members  of  the  standards  drafting  committee  as  analysts,  whose  primary 
responsibility  is  to  work  with  SASE  on  issues  of  format  and  organization, 
interacting  closely  with  the  other  committee  members  who  are  experts  in  the 
area  covered  by  the  standard.  Alternatively,  organizations  involved  in 
standards  activities  may  provide  analytical  services  to  their  committees  as 
a staff  support  function.  In  either  event,  analysis  should  be  closely 
coordinated  with  the  standards  formulation  process. 

For  a project  that  involves  the  formulation  of  a new  standard,  systematic 
analysis  using  SASE  should  begin  at  the  same  time  as  the  overall  project  of 
standards  drafting  and  be  closely  coordinated  with  it.  This  avoids  the 
possibility  of  the  analyst  appearing  as  an  intruder,  and  allows  the  analyst 
to  keep  up  with  the  experts . 

For  a project  that  involves  a revision  of  an  existing  standard,  it  is 
desirable  to  begin  analysis  of  the  standard  before  the  committee  begins 
considering  revisions.  Once  again,  this  allows  the  analyst  to  keep  up  with 
the  committee.  It  also  allows  a thorough  study  of  the  possible  flaws  in 
the  existing  provisions,  which  could  serve  as  part  of  the  rationale  for 
change . 

Once  the  analysis  has  been  undertaken,  it  should  be  kept  up  to  date  as  the 
project  continues.  There  are  several  advantages  accruing  from  concommitant 
analysis ; 


• it  provides  a firm,  rational  basis  for  recommendations  to  be  made 
to  the  experts ; 


• the  details  of  the  analysis  may  be  important  to  some  of  the  experts 
in  their  deliberations;  and 

• the  final  SASE  documentation  can  be  completed  and  released  with  the 
written  standard  or  very  soon  after  its  completion. 

Effective  interaction  between  the  analysts  and  the  experts  is  of  the  utmost 
importance.  Close  and  frequent  contacts  facilitate  the  work  and  greatly 
improve  the  likelihood  of  significant  benefit.  Analysis,  synthesis,  and 
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expression  of  any  standard  are  too  important  to  the  success  of  the  stand- 
ard-writing project  to  be  delegated  to  a format  committee  remote  from  the 
main  thrust  of  the  work.  The  analysts  should  interact  directly  with  the 
committee  concerned  with  the  substance  of  the  standard,  for  that  is  where 
the  key  issues  will  arise  and  the  decisions  will  be  made.  It  can  become 
easy  to  fall  into  adversative  positions  when  the  experts  and  the  analysts 
are  too  far  removed  from  one  another  because  of  the  organizational  struc- 
ture. Close  contact  increases  the  spirit  of  cooperation  and  lessens  the 
chance  of  the  analyst  antagonizing  the  experts.  Successful  interaction 
also  requires  quick  response. 

Typically,  recommendations  generated  by  the  analysts  come  in  the  form  of  a 
question  raised  or  of  an  improvement  suggested.  Both  forms  are  valid  but, 
with  every  recommendation,  it  must  be  clear  what  the  form  is  and  what  the 
appropriate  action  for  the  experts  is.  In  addition,  all  recommendations 
must  be  carefully  explained,  with  due  consideration  of  present  problems  and 
the  impacts  of  change.  Finally,  the  participants  in  such  projects  must 
frequently  conduct  critiques  of  their  work,  their  own  effectiveness  in  the 
work,  and  the  standard  that  they  are  working  on. 

In  summary,  the  following  items  are  critical  components  for  the  successful 
use  of  SASE  in  a standards  development  project: 

• begin  analysis  at  the  earliest  possible  time; 

• obtain  early  agreement  within  the  committee  on  the  interaction  be- 
tween experts  and  analysts; 

• conduct  a full,  detailed  analysis  early  and  keep  the  analysis  up  to 
date ; 

• cultivate  close  and  effective  interactions  between  experts  and  ana- 
lysts ; 

• make  all  recommendations  clear;  and 

• conduct  on-going  critiques. 

1 . 3 Organization  of  this  Document 

This  document  is  directed  primarily  to  analysts  participating  in  standard 
development  activities.  The  document  is  intended  to  provide  the  background 
on  the  SASE  methodology  and  tutorial  guidance  on  the  SASE  program.  It  is 
expected  that  the  document  will  be  used  in  conjunction  with  the  SASE  User 
Manual  [4] , both  to  provide  the  motivation  for  and  an  understanding  of  the 
features  in  SASE  and  to  serve  as  an  illustrative  guide  for  the  use  of  these 
features. 

Portions  of  this  document,  especially  Chapter  2 but  also  the  introductory 
material  and  examples  of  Chapter  3 and  Chapter  4,  should  be  of  interest  not 
just  to  analysts  but  to  all  experts  participating  in  standard  developing 
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committees.  This  material  will  provide  an  understanding  of  the  types  of 
assistance  that  can  be  provided  to  the  experts  by  analysts  using  SASE. 

A brief  overview  of  the  conceptual  model  incorporated  in  the  SASE  methodol- 
ogy and  of  the  representation  of  the  principal  components  of  a standard  in 
the  SASE  program  is  presented  in  Chapter  2. 

Detailed  descriptions  of  the  process  of  modelling  and  organizing  the  infor- 
mation of  a standard  according  to  the  conceptual  model  are  provided  in 
Chapter  3 and  Chapter  4.  Each  of  the  major  sections  of  these  chapters  is 
subdivided  into  three  parts : 

• a detailed  definition  of  the  concept  presented  in  the  section, 
including  background  information; 

• a discussion  of  proper  usage  of  the  concept,  containing  suggestions 
to  serve  as  tutorial  aids ; and 

• the  representation  of  the  concept  in  the  SASE  program. 

The  results  of  a study  of  a standard  for  concrete  quality  are  presented  in 
Appendix  A as  a practical  demonstration  of  the  SASE  methodology.  Virtually 
all  of  the  SASE  techniques  described  in  this  report  were  applied  in  the 
s tudy . 
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2.  OVERVIEW  OF  SASE 


This  chapter  presents  a brief  overview  of  the  conceptual  model  incorporated 
in  the  SASE  methodology  and  of  the  representation  of  the  principal  compo- 
nents of  a standard  in  the  SASE  program. 

2 . 1 The  SASE  Methodology 

This  overview  of  the  SASE  methodology  is  illustrated  by  a completed  analy- 
sis of  a section  of  a model  building  code  [1]  dealing  with  fire  escapes. 
The  text  of  the  fire  escape  example  is  shown  in  figure  2.1.  The  underlined 
portions  of  the  text  correspond  to  data  items  identified  in  the  analysis; 
the  numbers  in  the  right  margin  of  the  figure  are  datum  reference  numbers 
assigned  by  the  analyst. 

2.1.1  Provis ions 

The  basic  unit  of  a standard  is  a provision  or  normative  statement  stipu- 
lating that  a product  or  process  shall  have  or  be  assigned  some  quality.  A 
number  of  forms  of  provisions  fit  this  definition; 

• a performance  requirement,  e.g.,  "the  system  shall  maintain  an  ade- 
quate supply  of  hot  water," 

• a performance  criterion,  e.g.,  "hot  water  temperature  shall  be  con- 
trolled between  40°C  and  50®C," 

• a prescriptive  criterion,  e.g.,  "the  hot  water  tank  shall  have  a 
capacity  of  150  liters," 

• a determination  or  function,  e.g.,  "the  flow  q = av." 

Each  provision  has  the  function  of  assigning  a value  to  a data  item  or 
datum.  It  is  useful  to  distinguish  between  two  kinds  of  provisions  based  on 
their  usage  in  the  standard: 

• Requirements  are  provisions  that  directly  determine  compliance  with 
some  portion  of  a standard.  Such  provisions  normally  can  be  char- 
acterized as  satisfied  or  violated,  represented  by  the  Boolean  data 
values  true  or  false,  respectively. 

• Determinations  are  all  provisions  that  are  not  requirements.  Such 
provisions  are  normally  characterized  by  either  numerical  or  nomi- 
nal values,  including  Boolean,  but  are  not  amenable  to  character- 
ization as  satisfied  or  violated. 

Seven  requirements  were  identified  in  the  analysis  of  the  fire  escape 
example.  They  are  described  in  terms  of  their  corresponding  data  items  in 
the  following  section. 
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Section  623.0  Fire  Escapes 

623.1  Where  Permitted:  Except  in  use  grouts  L-2  and  L-3  (one-  2 

and  two-family  and  multi-family  dwellings),  fire  escapes  shall 

not  in  general  be  accepted  as  an  element  of  a required  means  of 
egress.  Fire  escapes  shall  be  permitted  only  by  special  order  1,3 
of  the  building  official,  in  existing  buildings  or  structures  4 

of  other  use  groups,  not  exceeding  five  (5)  stories  or  sixty-  6 

five  (65)  feet  in  height . when  constructed  in  accordance  with  7 

the  approved  rules  and  when  more  adequate  exitwav  facilities  9 

cannot  be  provided. 

623.2  Location:  When  located  on  the  front  of  the  building  and  10 

projecting  beyond  the  building  line,  the  lowest  landing  shall  11,12 

be  not  less  than  ten  (10)  or  more  than  fourteen  (14)  feet  above 
grade,  equipped  with  a counterbalanced  stairway  to  the  street  13 

and  with  fixed  ladder  to  the  roof.  In  alleyways  and  thorough-  14,15 

fares  less  than  thirty  (30)  feet  wide,  the  clearance  under  the  29 

lowest  landing  shall  not  be  less  than  fourteen  (14)  feet. 

623.3  Construction:  The  fire  escape  shall  be  designed  to  sup-  8 

port  a live  load  of  one  hundred  (100)  pounds  per  square  feet  16 

and  shall  be  constructed  of  steel  or  other  approved  noncombus-  17 , 30 
tible  materials. 

623.31  Dimensions:  Stairs  shall  be  at  least  twenty- two  (22)  31 

inches  wide  with  risers  not  more  and  treads  not  less  than  eight  21-23 

(8)  inches  and  landings  at  foot  of  stairs  not  less  than  forty  35 

(40)  inches  wide  by  thirty-six  (36)  inches  long . located  not  24-26 

more  than  eight  (8)  inches  below  the  access  window  or  door. 

623.32  Opening  Protectives:  Doors  and  windows  along  the  fire  34 

escape  shall  be  protected  with  three-quarter  (3/4)  hour  opening  27 
protectives  in  other  than  residence  buildings  of  use  groups  L-2 

and  L-3. 

623.33  Outside  Fire  Limits:  On  buildings  not  over  three  (3) 

stories  nor  more  than  forty  (40)  feet  in  height  located  outside 

the  fire  limits,  accomodating  not  more  than  twenty  (20)  per-  32 

sons ■ fire  escapes  may  be  constructed  of  wood  or  other  approved  33 
material  of  similar  combustible  characteristics. 

623.34  Within  Fire  Limits:  Within  Fire  District  No.  2,  fire  20,28 

escapes  may  be  constructed  of  wood  not  less  than  two  (2)  inches  18 

thick  on  buildings  of  type  3 or  type  4 construction  not  more  19 

than  three  (3)  stories  in  height. 


Figure  2.1  Text  of  fire  escape  example  with  data  items 
underlined  and  datum  reference  numbers  in  right  margin. 
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2.1.2  Data  Items 


A data  item  or  datum  is  a precise  identification  of  an  information  element 
occurring  in  a standard.  The  status  (satisfied  or  violated)  of  each  re- 
quirement is  represented  by  a datum.  Each  result  or  variable  generated  by 
a determination  is  a datum.  In  addition,  every  other  variable  referred  to 
in  a standard  but  not  explicitly  assigned  a value  by  some  provision  is  a 
datum.  For  example,  the  density  of  a material  may  be  referred  to,  but  not 
defined,  in  a standard.  Such  data  are  called  input  data;  their  values  are 
not  determined  by  the  standard  itself.  All  data  assigned  values  by  provi- 
sions of  the  standard  are  called  derived  data.  The  list  of  data  items  is 
similar  to,  but  typically  much  longer  than,  the  conventional  list  of  def- 
initions and  s3rmbols  found  in  present  standards. 

The  set  of  data  items  plus  the  expressions  of  the  rules  for  evaluating  and 
relating  the  data  items  contain  all  the  information  necessary  to  evaluate 
compliance  with  a standard. 

The  data  items  for  the  fire  escape  example  are  listed  by  reference  number 
in  table  2.1.  The  reference  numbers  were  assigned  as  the  analyst  identified 
each  datum  and  are  not  necessarily  in  the  order  of  appearance  in  the  text. 
Each  datum  is  described  by  a short  title.  It  is  instructive  to  compare  the 
titles  in  table  2.1  with  the  underlined  portions  of  text  in  figure  2.1. 
Frequently,  a verbatim  extraction  of  text  does  not  suffice  to  capture  the 
meaning  of  an  information  element  and  the  title  must  be  synthesized. 

Each  datum  in  table  2.1  is  also  described  by  the  source  of  its  value  (e.g., 
input  or  derived) ; and,  if  derived,  the  reference  numbers  of  the  ingredient 
data  items  on  which  its  value  depends  (see  section  2.1.4).  Note  that  datum 
5 in  the  table  is  neither  a derived  datum  nor  an  ingredient  of  any  datum. 
It  was  entered  by  the  analyst  expecting  to  encounter  a height  limit  within 
this  section  and  was  retained  because  it  may  be  an  ingredient  to  a datum  in 
another  section  of  the  standard. 

2.1.3  Decision  Tables 

A decision  table  is  used  to  represent  the  rules  for  assigning  a value  to  a 
derived  datum.  A decision  table  is  an  orderly  presentation  of  the  reason- 
ing leading  to  a decision.  It  is  easily  analyzed  to  assure  that  the  rea- 
soning leads  to  a unique  result  in  each  case  and  that  no  possibility  exists 
for  encountering  an  unanticipated  situation. 

The  seven  decision  tables  given  in  tables  2.2  through  2.8  correspond  to  the 
seven  requirements  identified  in  the  fire  escape  example. 

Each  decision  table  is  divided  into  four  quadrants  (in  this  representation, 
by  the  double  lines) . The  upper  left  quadrant  is  the  condition  stub  defin- 
ing all  logical  conditions  that  have  a bearing  on  the  actions.  The  lower 
left  quadrant  is  the  action  stub  defining  all  possible  actions.  The  upper 
right  quadrant  is  the  condition  entry  and  the  lower  right  quadrant  is  the 
action  entry.  The  rules  defining  the  logic  of  the  decision  table  are  the 
columns  spanning  the  entry  quadrants.  The  horizontal  rows  of  conditions 
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Table  2.1  Datum  list  for  fire  escape  example 


Reference 

Number  Title 

Source 

Ingredient 
Data  Items 

1 

Requirement  for  permission 
to  use  fire  escapes 

Derived 

2, 3, 4, 6, 7, 9 

2 

Use  group 

Input 

3 

Special  order  of  building 
official 

Input 

4 

Existing  building 

Input 

5 

Height  limit 

Input 

6 

Number  of  stories 

Input 

7 

Height  of  building 

Input 

8 

Requirement  for  design  load 
of  fire  escapes 

Derived 

16 

9 

Availability  of  more 
adequate  exitway 

Input 

10 

Front  of  building 

Input 

11 

Projecting  beyond  building 
line 

Input 

12 

Height  of  lowest  landing 
above  grade 

Input 

13 

Counterbalanced  stair  to 
street 

Input 

14 

Fixed  ladder  to  roof 

Input 

15 

Alley  or  thoroughfare  less 
than  30  feet  wide 

Input 

16 

Design  live  load 

Input 

17 

Steel  or  other  noncombustible 
material 

Input 

18 

Wood  not  less  than  2 inches 
thick 

Input 

10 


Table  2.1  Datum  list  for  fire  escape  example  (concluded) 


Reference 

Number  Title 

Source 

Ingredient 
Data  Items 

19 

Type  of  construction 

Input 

20 

Fire  district 

Input 

21 

Stair  width 

Input 

22 

Riser  height 

Input 

23 

Tread  width 

Input 

24 

Landing  width 

Input 

25 

Landing  length 

Input 

26 

Landing  distance  below  access 

Input 

27 

Hour  opening  protective 

Input 

28 

Within  fire  limits 

Input 

29 

Requirement  for  landing 
clearance 

Derived 

10,11,12,13,14,15, 

26 

30 

Requirement  for  material 
type 

Derived 

6,7,17,18,19,20,28, 

32,33 

31 

Requirement  for  stair 
dimensions 

Derived 

21,22,23 

32 

Number  of  occupants 

Input 

33 

Wood  or  similarly 
combustible  material 

Input 

34 

Requirement  for  fire  rating 
of  doors  and  windows 

Derived 

2,27 

35 

Requirement  for  landing 
dimensions 

Derived 

24,25 
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Table  2.2 


Requirement  for  permission  to  use  fire  escapes  (datum  number  1) 


1 2 E 


Use  group  L2  or  L3  (2) 

T 

F 

Special  order  of  building  official  (3)  AND 
existing  building  (4)  AND 
height  not  greater  than  5 stories  (6)  AND 
height  not  greater  than  65  feet  (7)  AND 
more  adequate  exitway  impossible  (9) 

T 

Requirement  = satisfied 

X 

X 

Requirement  = violated 

X 

Table  2.3  Requirement  for  design  load  of  fire  escapes  (datum  number  8) 


1 

1 

2 


1 2 


Design  live  load  > 100  psf  (16) 

T 

F 

Requirement  =■  satisfied 

X 

Requirement  = violated 

X 

12 


Table  2.4  Requirement  for  landing  clearance  (datxim  number  29) 


1 

2 

3 

4 

5 

6 

E 

1 

Front  of  building  (10) 

T 

T 

F 

F 

T 

F 

2 

Projecting  beyond  building  line  (11) 

T 

F 

T 

3 

Counterbalanced  stair 
to  street  (13)  AND 
fixed  ladder  to  roof  (14)  AND 
10  ft  < height  of  lowest 
landing  (12)  < 14  ft 

T 

• 

F 

4 

Alley  or  thoroughfare  < 30  ft  wide  (15) 

F 

• 

T 

F 

T 

5 

Height  of  lowest  landing  (12)  > 14  ft 

• 

• 

T 

• 

F 

6 

Landing  dist.  below  access  (26)  < 8 in 

T 

T 

T 

T 

1 

Requirement  = satisfied 

X 

X 

X 

X 

2 

Requirement  = violated 

X 

X 

X 

Table  2.5  Requirement  for  material  type  (datum  number  30) 


1 

2 

3 

4 

5 

E 

1 

Steel  or  other  noncombustible 
material  (17) 

T 

- 

- 

- 

- 

2 

Within  fire  limits  (24) 

F 

F 

T 

T 

3 

Height  < 3 stories  (6)  AND 
height  < 40  feet  (7)  AND 
number  of  occupants  < 20  (32) 

T 

F 

4 

Wood  or  similarly  combustible 
material  (33) 

- 

T 

T 

T 

T 

5 

Within  fire  district  2 (20)  AND 
type  3 or  type  4 construction  (19)  AND 
wood  < 2 inches  thick  (18)  AND 
height  < 3 stories  (6) 

T 

F 

1 

Requirement  = satisfied 

X 

X 

X 

2 

Requirement  = violated 

X 

X 

X 
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Table  2.6  Requirement  for  stair  dimensions  (datum  number  31) 


1 E 


1 

Stair  width  (21)  > 22  in 

T 

2 

Riser  height  (22)  < 8 in 

T 

3 

Tread  width  (23)  > 8 in 

T 

1 

Requirement  = satisfied 

X 

2 

Requirement  = violated 

X 

Table  2.7  Requirement  for  fire  rating  of  doors  and  windows 
(datum  number  34) 

12  3 


1 

Use  group  L2  or  L3  (2) 

T 

F 

F 

2 

Fire  rating  of  doors  and  windows  > 3/4  hr  (27) 

T 

F 

1 

Requirement  = satisfied 

X 

X 

2 

Requirement  = violated 

X 

Table  2.8  Requirement  for  landing  dimensions  (datum  number  35) 


1 E 


1 

Landing  width  >40  in  (24) 

T 

2 

Landing  width  > 36  in  (25) 

T 

1 

Requirement  = satisfied 

X 

2 

Requirement  = violated 

X 

14 


and  actions  and  the  vertical  columns  of  rules  are  numbered  in  each  decision 
table  for  reference  purposes. 

A simple  nomenclature  is  used  in  the  decision  tables.  A "T"  or  "Y"  in  a 
condition  entry  indicates  that  the  condition  must  be  true  for  the  particu- 
lar rule  to  apply.  An  "F"  or  "N"  in  a condition  entry  indicates  that  the 
condition  must  be  false.  An  "I"  or  in  a condition  entry  indicates  the 
condition  is  immaterial;  it  can  be  either  true  or  false.  A in  a condi- 
tion entry  indicates  the  condition  is  implicitly  false  because  of  another 
condition,  and  a indicates  the  condition  is  implicitly  true.  An  "X"  in 
an  action  entry  indicates  which  action  is  to  be  taken  for  a given  rule. 

Tables  2.2,  2.4,  2.5,  2.6,  and  2.8  have  a last  rule  labeled  "E"  (for  Else) 
that  is  matched  by  any  combination  of  conditions  not  matched  by  any  preced- 
ing rules.  The  action  corresponding  to  an  else  rule  is  either  the  issuance 
of  an  error  message  (if  the  combination  of  conditions  is  impossible)  or  the 
assignment  of  "violated"  to  the  datum  corresponding  to  the  table  (if  the 
combination  of  conditions  is  unacceptable) . 

The  numerals  in  parentheses  in  the  condition  stubs  of  the  decision  tables 
are  the  reference  numbers  of  the  data  items  that  must  be  known  in  order  to 
evaluate  the  particular  condition.  Each  datum  referenced  in  a condition 
stub  is  an  ingredient  of  the  datum  defined  by  the  action.  The  latter  datum 
is  termed  a dependent  of  each  of  its  ingredients. 

Table  2.2  illustrates  most  of  this  decision  table  nomenclature.  In  this 
table,  rule  1 applies  if  condition  1 is  true  since  condition  2 is  then 
immaterial;  action  1 is  taken.  Only  ingredient  datum  2 had  to  be  known  in 
order  to  determine  that  rule  1 applies  and  to  evaluate  the  dependent  datum. 
If  condition  1 is  false  and  condition  2 is  true,  rule  2 applies,  and  action 
1 also  is  taken.  For  all  other  combinations  (here,  only  one),  the  else 
rule  applies,  and  action  2 is  taken.  Ingredient  data  items  3, 4, 6, 7,  and  9 
had  to  be  known  in  addition  to  datum  2 to  determine  which  of  rule  2 and  the 
else  rule  applies  and  to  evaluate  the  dependent  datum. 

A decision  tree  can  be  generated  from  the  logic  represented  in  a decision 
table  to  explore  the  significance  of  the  else  rule.  The  decision  tree 
corresponding  to  table  2.5  is  shown  in  figure  2.2.  Each  of  the  else  rules 
in  the  decision  tree  represents  a combination  of  conditions  not  covered  by 
a rule  in  the  decision  table.  Each  such  combination  can  be  checked  to 
determine  whether  it  is  feasible  and  should  have  an  explicit  rule  and 
action.  The  else  rules  found  in  figure  2.2  turn  out  to  be  infeasible- - they 
describe  a material  that  is  neither  combustible  nor  noncombustible. 

2.1.4  Information  Network 

The  ingredient  data  items  are  those  whose  values  must  be  known  in  order  to 
evaluate  the  dependent.  For  example,  datum  1,  Requirement  for  the  Use  of 
Fire  Escapes,  has  ingredient  data  items  2,  3,  4,  6,  7,  and  9,  as  shown  by 
tables  2.1  and  2.2.  The  set  of  ingredient  data  items  is  called  the  ingre - 
dience  of  the  dependent.  Similarly,  the  set  of  data  items  dependent  on  an 
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Figure  2.2  Decision  tree  for  the  logic  in  table  2.5. 
Logical  tests  of  conditions  are  shown  as  diamonds  with 
"T"  and  "F"  labelling  the  branches  corresponding  to 
true  and  false  values  of  the  condition  tested. 


ingredient  datum  is  called  its  dependence . For  example,  datum  2,  Use 
Group,  has  dependents  1 and  34,  as  shown  by  tables  2.1,  2.2,  and  2.7. 

An  information  network  is  used  to  represent  the  precedence  relations  among 
the  data  items  in  the  standard.  Each  datum  corresponds  to  a node  in  the 
network  and  branches  are  drawn  from  each  ingredient  to  its  dependent 
datum(s).  The  information  network  graphically  represents  the  flow  of 
information  through  the  data  items  and  the  decision  points  in  the  set  of 
provisions.  Figure  2.3  shows  a portion  of  the  information  network  for  the 
fire  escape  example.  This  particular  example  leads  to  a shallow,  straight- 
forward network.  Many  standards  lead  to  complex  networks  many  levels  deep. 
It  should  be  apparent  that,  irrespective  of  its  complexity,  the  entire 
information  network  can  be  assembled  once  each  datum  and  its  direct  ingre- 
dients are  known. 

2.1.5  Classification  System 

A classification  system  based  on  a model  structure  for  provisions  [9]  is 
used  to  generate  outlines,  organizations,  and  indices  that  represent  the 
arrangement  and  scope  of  the  standard.  All  requirements  as  well  as  any 
determinations  that  are  likely  to  be  referred  to  directly  by  users  must  be 
classified. 

The  model  structure  of  a requirement  includes  two  parts,  a subject  and  a 
predicate.  The  subject  may  be  a physical  entity  (for  instance,  a part  of  a 
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Derived  data  items 


Figure  2.3  Portion  of  information  network  for  the  fire  escape  example 


building),  a process  (for  example,  design  or  manufacture),  or  a participant 
in  the  process  (for  example,  a designer,  builder,  or  regulatory  agency). 
The  predicate  is  a particular  quality  or  action  required  of  a subject  (for 
instance,  strength  or  stiffness  of  a building  part  or  submission  of  quality 
assurance  documents  from  a manufacturer) . The  classification  system  for  a 
standard,  then,  is  based  on  the  names,  called  classifiers . of  all  of  the 
subjects  and  predicates  covered  by  its  privision. 

The  classifiers  for  the  fire  escape  example  are  listed  in  table  2.9.  They 
were  selected  by  naming  the  subject  and  predicate  of  each  of  the  require- 
ments shown  in  table  2.1. 

The  list  of  classifiers  pertaining  to  a particular  provision  is  called  the 
argument  list  of  that  provision,  as  is  the  collection  of  lists  for  all  the 
provisions.  The  argument  list  for  the  fire  escape  example  is  given  in  table 

2.10.  The  list  of  provisions  coming  under  a particular  classifier  is  called 
the  scopelist  of  that  classifier,  as  is  the  collection  of  lists  for  all  the 
classifiers.  The  scopelist  for  the  fire  escape  example  is  shown  in  table 

2.11.  The  scopelist  can  be  generated  by  transposing  the  argument  lists  for 
all  the  provisions.  The  use  of  these  lists  is  discussed  in  Chapter  4. 

Once  selected,  the  classifiers  are  systematically  organized  into  a hier- 
archy to  represent  the  successively  finer  subdivisions  of  the  subjects  and 
the  required  qualities  (predicates)  falling  within  the  scope  of  a standard. 
Figure  2.4  provides  one  possible  hierarchy  of  classifiers  for  the  fire 
escape  example  with  one  field  for  subjects  under  the  principal  heading 
"building"  and  another  field  for  predicates  under  the  principal  heading 
"acceptability."  The  hierarchy  of  a major  standard  may  involve  many  fields. 
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Table  2.9  Classifier  list  for  the  fire  escape  example 

(a)  Subjects 


Reference 

Number 

Title 

1 

Fire  escape 

2 

Landing 

3 

Material 

4 

Doors  and  windows 

11 

Components 

12 

Stairs 

13 

Mechanical  parts 

14 

Apertures 

17 

Building 

(b)  Predicates 

Reference 

Number 

Title 

5 

Permitted  usage 

6 

Design  strength 

7 

Clearance 

8 

Combustibility 

9 

Dimensions 

10 

Fire  rating 

15 

Live  loads 

16 

Dead  loads 

18 

Acceptability 

18 


Table  2.10  Argument  list  for  the  fire  escape  example 


Provision 

Classifier 

1 

Requirement 

for 

permission  to  use  fire  escapes 

1 

Fire  escape 

5 

Permitted  usage 

8 

Requirement 

for 

design  load  of  fire  escapes 

1 

Fire  escape 

15 

Live  loads 

29 

Requirement 

for 

landing  clearance 

2 

Landing 

7 

Clearance 

30 

Requirement 

for 

material  type 

3 

Material 

8 

Combustibility 

31 

Requirement 

for 

stair  dimensions 

9 

Dimensions 

12 

Stairs 

34 

Requirement 

for 

fire  rating  of  doors  and  windows 

4 

Doors  and  windows 

10 

Fire  rating 

35 

Requirement 

for 

landing  dimensions 

2 

Landing 

9 

Dimensions 
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Table  2.11  Scopelist  for  the  fire  escape  example 


Classifier 

Provision 

1 

Fire  escape 

1 

Requirement 

for 

permission  to  use  fire  escapes 

8 

Requirement 

for 

design  load  of  fire  escapes 

2 

Landing 

29 

Requirement 

for 

landing  clearance 

35 

Requirement 

for 

landing  dimensions 

3 

Material 

30 

Requirement 

for 

material  type 

4 

Doors  and  windows 

34 

Requirement 

for 

fire  rating  of  doors  and  windows 

5 

Permitted  usage 

1 

Requirement 

for 

permission  to  use  fire  escapes 

6 

Design  strength 

7 

Clearance 

29 

Requirement 

for 

landing  clearance 

8 

Combustibility 

30 

Requirement 

for 

material  type 

9 

Dimensions 

31 

Requirement 

for 

stair  dimensions 

35 

Requirement 

for 

landing  dimensions 

10 

Fire  rating 

34 

Requirement 

for 

fire  rating  of  doors  and  windows 

11 

Components 

12 

Stairs 

31 

Requirement 

for 

stair  dimensions 

13 

Mechanical  parts 

14 

Apertures 

15 

Live  loads 

8 

Requirement 

for 

design  load  of  fire  escape 

16 

Dead  loads 

17 

Building 

18 

Acceptability 
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Subject  field 

Building 

Fire  escape 
Material 
Components 
Landing 
Stairs 

Mechanical  parts 

Apertures 

Doors  and  windows 


Predicate  field 

Acceptability 

Permitted  usage 

Design  strength 
Live  loads 
Dead  loads 

Combustibility 

Dimensions 

Clearance 

Fire  rating 


Figure  2.4  A hierarchy  of  classifiers  for  the  fire  escape  example 
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The  subject  and  predicate  fields  in  the  classifier  hierarchy  are  combined 
to  generate  three  related  representations  of  possible  arrangements  of  a 
standard.  An  organization  is  a tabular  arrangement  of  headings,  each 
heading  corresponding  to  a specific  classifier.  A possible  organization  for 
the  fire  escape  example  is  shown  in  figure  2.5. 

An  outline  contains,  in  addition  to  the  headings,  the  pertinent  provisions 
classified  under  the  selected  heading.  An  outline  for  the  fire  escape 
example  is  shown  in  figure  2.6.  As  an  illustration  of  the  use  of  an  outline 
(along  with  the  decision  tables  for  the  provisions)  in  the  expression  of  a 
standard,  new  text  has  been  generated  for  the  fire  escape  example  from  the 
outline  in  figure  2.6.  The  new  text  is  given  in  figure  2.7. 

Finally,  an  index  provides  an  alphabetized  listing  of  classifiers,  with  a 
listing  of  the  scopelist  of  each  classifier,  that  is,  of  the  provisions 
associated  with  each  classifier.  An  index  for  the  fire  escape  example  would 
be  a trivial  reordering  of  table  2.11  and  isn't  shown. 

2 . 2 The  SASE  Program 

2.2.1  SASE  Program  Summary 

The  SASE  program  is  an  integrated  collection  of  computer  aids  for  the  anal- 
ysis, synthesis,  and  expression  of  standards.  The  salient  features  of  the 
SASE  program  are: 

• integration  of  all  functions  into  a single  system; 

• maintenance  of  all  information  in  a database,  thus  providing  facil- 
ities to  store,  analyze,  modify,  and  combine  information  about  ver- 
sions of  a standard  as  it  progresses  through  its  "life  cycle"  of 
initial  formulation,  revisions,  modification,  adoption,  and  mainte- 
nance ; 

• convenient  user  interaction  for  entry,  analysis,  modification,  and 
display  geared  to  users  with  varying  levels  of  proficiency; 

• facilities  for  processing  and  combining  large  standards  subdivided 
into  several  units,  which  may  be  analyzed  or  synthesized  by  differ- 
ent groups  of  experts  or  analysts;  and 

• facilities  for  interfacing  with  additional  capabilities,  including 
text  generation  and  computer-aided  design,  to  be  developed  in  the 
future . 

The  SASE  program  provides  the  following  major  functions  to  the  analyst: 

« data  management  for  storage  and  maintenance  of  the  information  con- 
tained in  a standard; 

• analysis  to  check  decision  table  representations  of  provisions  of  a 
standard  for  uniqueness  and  completeness; 
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I.  Fire  escape 

A.  Permitted  usage 

1.  Material 

2 . Components 

B.  Dimensions 

1.  Material 

2 . Components 

a . Landing 

i.  Clearance 

b.  Stairs 

i.  Clearance 

c.  Mechanical  parts 
i.  Clearance 

C.  Design  strength 

1.  Live  loads 

a.  Material 

b . Components 

2.  Dead  loads 

a.  Material 

b . Components 

D.  Combustibility 

1.  Material 

2 . Components 

II.  Apertures 

A.  Fire  rating 

1.  Doors  and  windows 


Figure  2.5  An  organization  for  the  fire  escape  example 
generated  from  the  hierarchy  in  figure  2.4. 
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I.  Fire  escape 

A.  Permitted  usage 

- Requirement  for  permission  to  use  fire  escapes 

1.  Material 

2 . Components 

B.  Dimensions 

1.  Material 

2 . Components 

a . Landing 

- Requirement  for  landing  dimensions 
i.  Clearance 

- Requirement  for  landing  clearance 

b.  Stairs 

- Requirement  for  stair  dimensions 
i.  Clearance 

c . Mechanical  parts 
i.  Clearance 

C.  Design  strength 

1.  Live  loads 

- Requirement  for  design  load  of  fire  escape 

a.  Material 

b , Components 

2.  Dead  loads 

a.  Material 

b.  Components 

D.  Combustibility 

1.  Material 

- Requirement  for  material  type 

2 . Components 

II.  Apertures 

A.  Fire  rating 

1 . Doors  and  windows 

- Requirement  for  fire  rating  of  doors  and  windows 


Figure  2.6  An  outline  for  the  fire  escape  example 
corresponding  to  the  organization  in  figure  2.5. 
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SECTION  623.0:  FIRE  ESCAPE 


623.1  Permitted  Usage 

Fire  escapes  are  unconditionally  permitted  in  use  groups  L2  and  L3  (one- 
and  two-family  and  multi-family  dwellings).  In  all  other  use  groups, 
fire  escapes  are  permitted  only  on  existing  buildings  with  height  of  not 
more  than  5 stories  and  not  more  than  65  feet,  and  only  if  more  adequate 
exit  ways  do  not  exist,  by  special  order  of  the  building  official. 

623.2  Dimensions 

623.21  Landings.  No  landing  shall  be  less  than  40  inches  wide  and  36 
inches  long.  No  landing  shall  be  more  than  8 inches  below  the  bottom  of 
an  access  window  or  door.  Lowest  landings  which  project  beyond  the  front 
building  line  shall  have  counterbalanced  stairways  to  the  street,  fixed 
ladders  to  the  roof,  and  shall  be  between  10  and  14  feet,  inclusive, 
above  the  street.  Lowest  landings  in  alleyways  or  thoroughfares  less 

30  feet  wide  shall  not  be  less  than  14  feet  above  the  alley  or 
thoroughfare . 

623.22  Stairs.  Stairs  shall  be  not  less  than  22  inches  wide,  with 
risers  not  greater  than  8 inches  and  treads  not  less  than  8 inches. 

623.3  Design  Strength 

The  fire  escape  shall  be  designed  to  support  a minimum  live  load  of  100 
psf . 

623.4  Combustibility 

Steel  or  other  noncombustible  materials  are  unconditionally  acceptable 
for  the  fabrication  of  fire  escapes.  Wood  or  other  combustible  materials 
are  acceptable  for  the  fabrication  of  fire  escapes  outside  the  fire 
limits  if  the  building  height  is  not  greater  than  3 stories  and  not 
greater  than  40  feet,  and  if  the  occupant  load  is  not  greater  than  20 
persons.  Wood  at  least  2 inches  thick  is  acceptable  for  the  fabrication 
of  fire  escapes  within  the  fire  limits  if  the  building  is  within  Fire 
District  2,  is  of  type  3 or  type  4 construction,  and  has  a height  not 
greater  than  3 stories. 

623.5  Fire  Rating  of  Building  Aperture 

For  use  groups  other  than  L2  or  L3 , the  fire  rating  of  doors  and  windows 
providing  access  to  fire  escapes  must  be  at  least  3/4  hour. 


Figure  2.7  New  text  for  the  fire  escape  example 
generated  from  the  outline  in  figure  2.6. 
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• information  network  model  which  enables  the  evaluation  of  relations 
among  provisions  of  a standard  and  provides  checks  to  ensure  that 
these  relations  are  connected  and  acyclic; 

• organization  model  which  permits  the  exploration  of  alternative 
ways  of  organizing  a standard  without  losing  information  contained 
in  the  document  or  changing  the  standard's  meaning;  and 

• index  generator  which  extracts  information  from  a given  organi- 
zation of  a standard. 

2.2.2  SASE  Database  Organization 

The  components  of  standards  represented  in  SASE  are  called  entities.  The 
entities  are  organized  into  three  groups,  according  to  type,  and  each  group 
has  an  associated  set  of  commands  specifying  the  actions  to  be  performed  on 
the  designated  entities. 

Each  entity  is  defined  by  the  value  of  a set  of  attributes,  one  of  which 
serves  as  the  reference  (or  key)  for  uniquely  identifying  a specific  enti- 
ty. 

The  three  groups  are  briefly  discussed  below.  In  the  discussion,  reserved 
words  in  the  SASE  program,  such  as  entity  names,  attribute  labels,  and 
commands  are  shown  in  capital  letters. 

Organizational  Entities.  This  group  of  entities  refers  to  the  global  orga- 
nizing elements  in  the  SASE  database,  and  includes: 

• STANDARD  - the  specific  standard  currently  under  consideration; 

• VERSION  - a particular  stage  of  a standard  (e.g.,  original,  trial, 
modification,  adopted,  etc.)  and 

« CHAPTER  - a major  subdivision  of  the  current  version. 

Organizational  entities  are  identified  by  name  and  contain  attributes  such 
as  title  and  description. 

The  SASE  commands  applicable  to  organizational  entities  are: 

• CREATE  a new  entity; 

• USE  a previously  defined  entity; 

• ADD,  MODIFY,  AND  DELETE  attributes; 

• LIST  entities  currently  in  database;  and 
® DESTROY  an  entity. 
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Basic  Entitles.  This  group  of  entities  contains  the  detailed  information 
about  a standard,  and  includes; 

• DATUM  - representing  individual  data  items; 

• TABLE  - representing  individual  decision  tables; 

• FUNCTION  - representing  functions;  and 

• CLASSIFIER  - representing  individual  classifiers. 

DATUM  and  CLASSIFIER  entities  are  identified  by  a reference  number.  TABLE 
and  FUNCTION  entities  are  identified  by  the  reference  number  of  their  cor- 
responding DATUM.  The  specific  attributes  of  each  entity  are  discussed  in 
the  following  chapters. 

The  SASE  commands  applicable  to  this  class  of  entities  are: 

• ENTER  an  initial  definition; 

• ADD,  MODIFY,  OR  DELETE  attributes; 

• DISPLAY  an  entity  or  set  of  entities; 

• DELETE  an  entity. 

Derived  Entities.  This  group  contains  entities  generated  from  the  basic 
entities,  and  includes: 

• TREE  generated  from  a decision  table; 

• NETWORK  generated  from  the  data  items ; 

• HIERARCHY  generated  from  the  classifiers; 

• SCOPELIST  generated  from  the  hierarchy  and  data  items; 

• INDEX  generated  from  the  scopelist; 

• ORGANIZATION  generated  from  the  classifiers; 

• OUTLINE  generated  from  the  classifiers  and  data  items. 

ORGANIZATION  entities  are  identified  by  a reference  number.  TREE  entities 
are  identified  by  the  reference  number  of  the  decision  tables  from  which 
they  are  generated.  The  other  entities  in  this  group  do  not  have  a refer- 
ence, as  (in  the  present  version  of  SASE)  only  one  entity  of  each  type  can 
exist  at  any  one  time  in  a VERSION  of  a standard. 

The  SASE  commands  applicable  to  this  group  are: 

• GENERATE  to  derive  the  entity; 
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DISPLAY  the  entity; 


• DELETE  the  entity. 

In  addition,  an  ORGANIZATION  may  be  initially  ENTERed  by  the  user  instead 
of  being  GENERATEd  at  the  same  time  as  its  associated  OUTLINE.  Because  the 
construction  of  satisfactory  ORGANIZATIONS  and  OUTLINES  is  a complex  pro- 
cess, interactive  dialog  modes  are  made  available  to  the  user  including  the 
ability  to  interrupt  and  then  CONTINUE  their  entry. 

The  hierarchical  relationships  among  the  entities  in  the  SASE  database  is 
shown  in  figure  2.8. 

The  combinations  of  command/entity  pairs  available  in  the  SASE  program  are 
shown  in  table  2.12. 
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Figure  2.8  Organization  of  the  SASE  Database 


Table  2.12  Available  SASE  command/entity  combinations 


Commands 

(create) 

( change ) 

(examine) 

(remove) 

R 

E 

G 

S 

C 

E 

E 

0 

D 

D 

C 

N 

M 

Q 

N 

I 

E 

D 

R 

E 

E 

0 

u 

T 

S 

S 

E 

E 

N 

R 

D 

E 

I 

L 

P 

T 

L 

A 

T 

A 

A 

I 

N 

N 

U 

I 

L 

R 

E 

T 

E 

T 

D 

F 

C 

U 

S 

S 

A 

0 

T 

Entities 

E 

R 

E 

D 

Y 

E 

E 

E 

T 

Y 

Y 

E 

(organizational) 

STANDARD 

X 

X 

xi 

X 

X 

X 

X^ 

VERSION 

X 

X 

X 

X 

X 

X 

X 

CHAPTER 

X 

X 

X 

X 

X 

X 

X 

(basic) 

DATUM 

X 

X 

X 

X 

X 

X 

TABLE 

X 

X 

X 

X 

X 

X 

FUNCTION 

X 

X 

X 

X 

X 

CLASSIFIER 

X 

X 

X 

X 

X 

X 

(derived) 

TREE 

X 

X 

X 

NETWORK 

X 

X 

X 

HIERARCHY 

X 

X 

X 

SCOPELIST 

X 

X 

X 

INDEX 

X 

X 

X 

ORGANIZATION 

X 

X 

X 

X 

X 

OUTLINE 

X 

X 

X 

X 

1 


Only  non-key  attributes  can  be  modified  or  deleted. 
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3.  MODELLING  THE  INFORMATION  OF  A STANDARD 


This  chapter  presents  the  SASE  techniques  for  modelling  the  information  of 
a standard.  The  model  is  essentially  independent  of  the  organization  and 
expression  of  the  information.  Major  sections  are:  Data  Items,  Provi- 
sions, Decision  Tables,  Decision  Trees,  Functions,  and  Networks.  The 
reader  is  encouraged  to  examine  the  Appendix  A,  which  presents  an  example 
to  illustrate  the  application  of  these  techniques  to  a standard. 

3 . 1 Data  Items 

3.1.1  Definition 

A data  item  or  datum  is  an  information  element  occurring  in  a standard. 
Conventionally,  a standard  contains  a list  of  definitions  of  key  informa- 
tion elements  and  a table  of  nomenclature  for  information  elements  identi- 
fied by  symbols.  All  these  information  elements  are  identified  as  data 
items  in  SASE.  For  a complete  representation,  SASE  typically  requires  many 
additional  data  items  not  normally  included  in  definitions  or  the  table  of 
symbols . 

The  identification  of  data  items  representing  the  information  content  of  a 
standard  is  somewhat  analogous  to  the  parsing  of  sentences.  The  identifi- 
cation of  significant  information  elements  to  be  designated  as  data  items 
has  to  be  guided  by  the  analyst's  experience  and  "feel"  for  the  intent  and 
scope  of  the  standard  being  analyzed.  It  is  best  to  approach  this  task 
incrementally,  initially  identifying  only  obvious  key  data  items,  and  then 
supplementing  these  as  the  analysis  proceeds  in  depth. 

3.1.2  Proper  Usage 

The  selection  of  data  items  must  be  guided  by  the  analyst's  experience  and 
judgment.  The  following  suggestions  may  be  of  assistance. 

Granularity . New  users  of  SASE  have  a tendency  to  identify  more  data  items 
than  necessary  for  describing  the  intent  and  content  of  a standard.  It  is 
important  to  use  the  right  "granularity"  and  identify  only  the  meaningful 
data  items.  Additional  items  can  always  be  entered  later,  say,  when  a 
detailed  decision  table  analysis  identifies  additional  ingredients. 

Existence- type  items.  It  is  easy  to  overlook  Boolean  data  items  specifying 
a true  or  false  quantity,  such  as  the  existence  of  a particular  object  or 
state.  Thus,  to  represent  the  sentence:  "If  stiffeners  are  provided  and 
they  are  spaced  ...",  a Boolean  data  item,  "stiffeners  provided"  is  needed 
in  addition  to  the  numeric  data  item  "stiffener  spacing". 

Options  and  alternatives . Standards  frequently,  contain  words  such  as  "op- 
tionally" , "preferably"  or  "alternately",  indicating  user  choices.  It  is 
important  to  identify  each  of  these  as  individual  Boolean  data  items,  with 
appropriate  titles  such  as  "option  desired"  or  "alternate  exercised" . 
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Regulatory  options.  Similar  to  the  above,  standards  contain  statements 
such  as  "building  official  may  require",  "values  satisfactory  to  the  build- 
ing official,"  etc.  All  such  options  must  again  be  identified  as  specific 
data  items,  with  appropriate  titles  such  as  "required  by  building  official" 
or  "acceptable  to  building  official." 

Use  of  Boolean  vectors.  Compactness  and  clarity  of  representation  can  be 
achieved  by  the  use  of  Boolean  vectors  instead  of  separate  individual 
Boolean  data  items.  Thus,  a single  data  item  -'building  type"  with  possible 
values  of  "new"  and  "existing"  is  preferable  to  two  separate  Boolean  data 
items.  Boolean  vectors  can  be  extended  to  more  than  two  entries,  such  as  a 
"building  category"  item  with  possible  values  of  "A",  "B",  "C" , or  "D" . 

Data  items  such  as  "load  type"  and  "element  type"  fall  into  this  category. 
It  will  be  seen  in  section  3.3  that  many  of  the  conditions  in  decision 
tables  are  directly  in  the  form  of  "Boolean  vector  datum  = one  of  its 
possible  values".  It  is  good  practice  to  use  the  COMMENT  field  to  record 
the  possible  values  of  a Boolean  vector  datum. 

3.1.3  Representation 

Each  data  item  is  represented  in  SASE  by  a datum  entity.  The  attributes 
describing  a datum  are  discussed  below. 

REFERENCE  NUMBER.  The  reference  number  is  a numeric  key  for  identifying 
the  datum.  The  reference  number  must  be  unique  within  a version.  A con- 
venient identification  scheme  is  to  use  a five -digit  reference  number,  the 
first  two  digits  referring  to  the  chapter  and  the  last  three  digits  sequen- 
tially assigned  within  the  chapter  in  increments  of  10,  thereby  providing 
space  for  reference  numbers  for  data  items  to  be  inserted  later. 

NAME . Any  short,  mnemonically  meaningful  alphabetic  designation.  While 
this  attribute  can  be  useful  now  as  a memory  aid  to  the  analyst,  its  pri- 
mary use  will  be  in  executable  computer  programs  that  represent  the  stan- 
dard. 

TITLE . Any  descriptive  title  of  the  datum  entered,  as  a text  string.  Its 
most  common  use  is  in  the  preparation  of  the  index. 

SECTION . The  alphanumeric  designation  of  the  section  in  the  existing  stan- 
dard. This  and  the  PAGE  attribute  are  used  for  cross-referencing  to  the 
text  of  an  existing  standard. 

PAGE ■ The  page  number  in  the  existing  standard. 

VALUE . This  attribute  defines  the  kind  of  value  used  for  expressing  the 
data  item,  and  can  be  one  of  the  following: 

• NUMERIC,  meaning  that  the  data  item  is  expressed  as  a number; 

• BOOLEAN,  meaning  that  the  data  item  is  a fact  (a  true  or  false 
quantity) ; or 
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• BV  for  Boolean  vector,  meaning  that  the  data  item  can  take  on  a 
value  from  a fixed  list  or  vector  of  distinct  names  or  numbers. 

SOURCE . Designates  whether  the  datum  is  INPUT  or  DERIVED  from  other  data 
items.  This  and  the  following  three  attributes  relate  to  the  position  of 

the  datum  in  the  information  network,  which  will  be  discussed  further  in 
section  3.2  through  3.6. 

TYPE . If  the  datum  is  DERIVED,  this  attribute-  designates  whether  the  deri- 
vation is  by  means  of  a decision  TABLE  (see  section  3.3)  or  a FUNCTION  (see 
section  3.5). 

UTILIZATION . If  the  datum  is  DERIVED,  this  attribute  designates  whether 
the  datum  is  a REQUIREMENT  or  a DETERMINATION  (see  section  3.2). 

INGREDIENTS . If  the  datum  is  DERIVED,  the  list  of  ingredient  data  items  is 
given,  identified  by  their  dattim  reference  numbers. 

STATUS . Designates  whether  the  dattim  is  CLASSIFIED  or  UNCLASSIFIED.  This 
and  the  ARGUMENT  attribute  relate  to  the  position  of  the  datum  in  the 
classification  hierarchy,  which  is  discussed  in  Chapter  4. 

ARGUMENTS . If  the  datum  is  CLASSIFIED,  the  list  of  its  classifiers  is 
given,  identified  by  their  classifier  reference  numbers.  The  argument  list 
may  be  preceded  by  the  words  INDEX  or  OUTLINE,  designating  that  the  datum 
be  included  in  the  index  or  outline  only. 

EQUIVALENTS . In  the  analysis  of  existing  standards,  the  situation  fre- 
quently arises  where  the  text  uses  a variety  of  names  for  what  is  actually 
a single  thing.  Such  equivalents  initially  can  be  cross-referenced  by 
their  datum  reference  numbers  as  they  are  detected  and  the  duplication 
subsequently  eliminated. 

COMMENT . Any  descriptive  information  or  comment  may  be  entered  as  a text 
string . 

3 . 2 Provisions 
3.2.1  Definition 

Provisions  are  the  basic  units  of  a standard.  Each  provision  is  a norma- 
tive statement,  stipulating  that  some  object  or  process  within  the  scope  of 
the  standard  is  to  have  a certain  quality  or  property. 

Provisions  are  distinguished  by  their  use: 

• Requirements  are  provisions  that  directly  determine  compliance  with 
the  standard;  they  are  Boolean  valued,  with  the  values  of  true  or 
false  interpreted  as  satisfied  or  violated,  respectively;  while 
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• Determinations  are  all  other  provisions;  these  may  include  numeri- 
cal, nominal,  and  Boolean  valued  items  which  can  not  be  character- 
ized as  satisfied  or  violated. 

Requirements  contain  two  basic  components:  a subject  and  a predicate.  The 

subject  is  a physical  entity,  a process  or  a participant  in  the  process, 
and  the  predicate  defines  the  particular  quality  required  of  the  subject. 

Requirements  play  a key  role  in  the  SASE  methodology.  On  the  one  hand, 
they  are  the  highest  nodes  of  the  information  network  (see  section  3.6): 
the  information  network  traces  the  data  items,  which  when  evaluated,  deter- 
mine whether  the  stipulations  of  the  standard  are  satisfied  or  not.  On  the 
other  hand,  requirements  are  the  lowest  nodes  of  the  classification  system 
(see  Chapter  4)  : the  hierarchy  of  classifiers  defining  the  scope  and 

organization  of  the  standard  is  built  up  from  the  "elementary"  classifiers 
defining  the  subjects  and  predicates  of  the  requirements. 

Harris  and  Wright  [9]  define  six  types  of  requirements; 

• Basic  requirements  have  a singular  subject  and  a singular  predi- 
cate. They  do  not  directly  depend  on  other  requirements. 

« Multiple  requirements  have  plural  subject  and/or  predicates.  They 
do  not  directly  depend  on  other  requirements . 

• Cumulative  requirements  depend  unconditionally  only  on  other  re- 
quirement data  items.  The  logic  of  the  provision  does  not  contain 
any  original  requirements . 

• Application  requirements  depend  conditionally  on  at  least  one  of 
the  ingredient  requirements.  The  provision  does  not  contain  an 
original  requirement,  nor  is  it  equivalent  to  a new  basic  require- 
ment . 

® Synthetic  requirements  are  like  application  requirements  except 
that  they  are  equivalent  to  a new  basic  requirement. 

• Mixed  requirements  depend  directly  on  other  requirements  (either 
conditionally  or  unconditionally)  and  the  provision  does  contain  an 
original  statement  of  a requirement. 

3.2.2  Proper  Usage 

In  synthesis.  In  synthesizing  a new  or  revised  standard,  it  is  important 
not  to  constrain  the  organizational  system  from  developing  alternative  ar- 
rangements based  on  the  classifier  hierarchy.  Therefore,  it  is  recommended 
that  [ 9 ] : 

• Mixed  requirements  not  be  used; 

• Cumulative  requirements  not  be  used; 
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• Multiple  Requirements  be  used  only  in  those  instances  in  which  the 
constituent  basic  requirements  would  be  most  likely  to  remain 
together  in  all  practicable  arrangements,  and  then  only  with  cau- 
tion; and 

• Application  requirements  that  simply  group  ingredient  requirements 
not  be  used. 

In  analysis.  In  analyzing  or  representing  an  existing  standard,  it  will  be 
frequently  found  that  individual  requirements  are  lumped  together,  i.e., 
that  a section  or  even  a single  existing  provision  may  contain  several 
unrelated  individual  requirements.  The  analyst  may  be  tempted  to  create 
one  or  more  cumulative  requirements  to  express  all  the  requirements  of  the 
section  or  original  provision.  This  practice  is  to  be  avoided  because 
cumulative  requirements  constrain  the  exploration  of  alternative  arrange- 
ments; also,  cumulative  requirements  will  be  difficult  to  classify  by  the 
procedures  described  in  Chapter  4. 

3.2.3  Representation 

In  SASE,  provisions  are  represented  by  the  data  items  that  carry  the  value 
of  the  provision.  Data  items  representing  provisions  are  distinguished  by 
the  following  attribute  values : 

• SOURCE  is  DERIVED,  since,  by  definition,  the  value  of  the  provision 
must  be  derived  from  the  values  of  other  ingredient  data  items ; 

• TYPE  is  either  TABLE  or  FUNCTION,  depending  on  how  the  logic  of 
derivation  is  expressed; 

• UTILIZATION  is  either  REQUIREMENT  or  DETERMINATION;  and 

• the  list  of  INGREDIENTS  is  non-empty. 

Furthermore,  all  requirements,  as  well  as  many  key  determinations,  will 
have  non-empty  lists  of  ARGUMENTS  since  they  are  to  be  located  using  the 
classification  system. 

3 . 3 Decision  Tables 
3.3.1  Definition 

Decision  tables  are  used  to  represent  and  examine  the  logical  structure  of 
individual  requirements  in  a standard.  They  may  also  be  used  for  all  other 
data  items  whose  value  is  derived  by  procedures  or  rules  described  in  the 
standard.  The  following  discussion  begins  with  a general  description  of 
decision  tables  before  arriving  at  the  specific  form  of  decision  tables 
used  in  SASE. 

General . A decision  table  defines  a set  of  rules  specifying  certain  ac- 
tions to  be  executed  based  on  a specific  set  of  conditions.  Decision 
tables  are  a convenient  means  to  express  the  logic  for  a set  of  decisions. 
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Decision  tables  were  developed  in  the  late  1950' s to  describe  logical 
problems  for  computer  programming  when  flow  charting  proved  to  be  too 
complex  and  cumbersome.  Decision  tables  have  met  with  success  because  they 
require  an  overall  analysis  of  situations  involving  parallel  thought  pro- 
cesses. Written  text  and,  to  some  extent  flow  charts,  both  describe  se- 
quential thought  patterns.  References  [14,  11]  contain  general  information 
on  decision  tables. 

A decision  table  is  composed  of  conditions,  actions,  and  rules.  A condi- 
tion is  a logical  statement  that  may  have  only  one  of  two  values;  true  or 
false.  An  action  in  a general  sense  is  any  operation,  e.g.,  it  may  be  the 
assignment  of  a value  to  a variable  by  means  of  a formula,  or  a statement 
that  prescribes  a set  of  conditions  in  order  that  a specified  set  of  ac- 
tions can  be  performed.  A decision  table  is  a structure  for  defining  a set 
of  related  rules.  The  conventional  structure  of  a decision  table  is  shown 
in  table  3.1. 

The  condition  stub  lists  each  condition  in  the  table,  one  to  a row.  The 
action  stub  does  the  same  for  the  actions.  The  condition  entry  lists  the 
combinations  of  values  of  the  conditions,  one  set  to  a column.  Each  column 
in  the  condition  entry  defines  a rule.  The  action  entry  indicates  which 
actions  are  to  be  executed  for  each  rule.  The  rule  is  a logical  AND  func- 
tion, that  is,  the  rule  is  not  satisfied  unless  each  of  the  condition 
entries  it  contains  is  matched. 

Extended  Entry  Tables.  The  most  general  form  of  decision  table  is  known  as 
an  extended  entry  table.  The  statements  contained  in  the  stubs  of  these 
tables  are  generally  incomplete,  in  that  the  stub  and  an  entry  value  to- 
gether make  a complete  statement.  This  form  of  decision  table  is  very 
flexible  and  is  readily  interpreted  by  readers.  Many  tables  in  existing 
standards  are  essentially  of  this  type,  although  the  physical  arrangement 
is  generally  not  as  shown  in  table  3.1.  For  example,  consider  a sample 
provision  taken  from  [15]  and  shown  in  table  3.2. 
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Table  3.2  Sample  provision 


Specific  minimum  yield 
point  of  lowest  strength 
steel  being  joined 

Electrode 

classification 

ASTM 

Permissible  stress  in 
shear  on  throat  of 
fillet  or  plug  welds 

< 36  ksi 

A233E60 

13.6 

ksi 

> 36  ksi  but 

A233E60 

13.6 

ksi 

< 50  ksi 

A233E70 

15.8 

ksi 

> 50  ksi 

A316E70 

15.8 

ksi 

A326E80 

17.7 

ksi 

In  this  example,  the  first  two  columns  correspond  to  conditions,  the  third 
column  corresponds  to  an  action,  and  the  rows  correspond  to  rules.  This 
same  information  is  rewritten  as  an  extended  entry  decision  table  in  table 
3.3. 

In  many  standards,  ingenious  table  formats  have  been  devised  to  represent 
the  logic  associated  with  a particular  decision  when  a narrative  descrip- 
tion is  not  practical.  However,  the  tables  become  hard  to  interpret  when 
more  than  two  or  three  conditions  are  involved.  Extended  entry  decision 
tables  are  by  no  means  new  or  unique,  but  the  formal  structure  that  allows 
the  combination  of  many  conditions  was  not  developed  fully  until  the  1950' s 
[1^]. 

Limited  Entry  Tables.  Primarily  because  they  are  so  flexible,  extended 
entry  decision  tables  do  not  lend  themselves  to  a routine  analysis  of  their 
logic,  and  are  difficult  for  computer  programs  to  interpret  automatically. 
A more  widely  used  form  of  decision  table,  the  limited  entry  form,  avoids 
these  problems.  The  condition  stub  of  limited  entry  tables  contains  only 
complete  logical  statements  which  can  have  values  of  true  or  false.  The 


Table  3.3  Extended  entry  decision  table 


Minimum  yield  point 
of  lowest  strength 
steel  is 

<36 

ksi 

>36  but 
<50  ksi 

>36  but 
<50  ksi 

>50 

ksi 

>50 

ksi 

ASTM  electrode  is 

A233E60 

A233E60 

A233E70 

A316E70 

A316E80 

Permissible  shear 

13.6 

13.6 

15.8 

15.8 

17.7 

stress  = 

ksi 

ksi 

ksi 

ksi 

ksi 
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condition  entry  contains  only  the  values  of  the  conditions  (true  or  false) 
and  the  action  entry  contains  an  "X"  if  an  action  is  to  be  executed  or  a 
blank  if  not.  An  elementary  extension  of  the  concept  allows  the  use  of  an 
immaterial  entry  in  the  condition  entry,  which  means  that  the  particular 
rule  does  not  depend  on  the  value  of  the  condition  for  the  row  with  the 
immaterial  entry.  Conventional  symbols  used  in  limited  entry  tables  are: 
"T"  or  "Y"  for  true,  "F"  or  "N"  for  false,  and  an  "I",  dot,  or  blank  for 
immaterial  in  the  condition  entry;  a blank  or  a dash  for  "don't  execute" 
and  an  "X"  for  "execute"  in  the  action  entry. 

Extended  entry  tables  may  be  converted  to  limited  entry  tables  in  a 
straightforward  manner.  Table  3.4  contains  the  conversion  of  the  extended 
entry  table  shown  in  table  3.3.  The  new  table  has  the  same  number  of  rules 
as  the  original  table,  but  considerably  more  conditions  and  actions.  Each 
extended  entry  condition  must  be  divided  so  that  all  of  its  possible  re- 
sponses can  be  covered  by  limited  entry  conditions.  Thus,  the  first  condi- 
tion of  table  3.3  is  divided  into  two  limited  entry  conditions  that  are 
capable  of  defining  the  three  bounded  ranges.  The  second  condition  of  table 
3.3  is  divided  into  four  limited  entry  conditions,  one  for  each  of  the 
unique  entries  in  the  original  condition. 

Preparation  of  Conditions.  Actions,  and  Rules.  One  of  the  keys  to  the 
successful  use  of  decision  tables  in  the  analysis  and  synthesis  of  stan- 
dards is  the  proper  formulation  of  condition  and  action  stubs.  There  are 
two  fundamental  principles  for  the  use  of  decision  tables  to  represent, 
provisions  of  standards. 

The  first  principle  is  that  each  decision  table  establishes  the  value  for 
only  one  data  item.  This  restriction  allows  each  decision  table  to  be 


Table  3.4  Limited  entry  decision  table 


F„  < 36  ksi 

j 

T 

F 

F 

F 

F 

Fy  < 50  ksi 

T 

T 

T 

F 

F 

A233E60 

T 

T 

F 

F 

F 

A233E70 

F 

F 

T 

F 

F 

A316E70 

F 

F 

F 

T 

F 

A316E80 

F 

F 

F 

F 

T 

F.^  = 13.6  ksi 

X 

X 

= 15.8  ksi 

X 

X 

F^  = 17.7  ksi 

X 
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uniquely  associated  with  one  datum,  which  becomes  a node  in  the  information 
network,  and  it  allows  the  ready  determination  of  the  ingredients  of  that 
node.  The  only  allowable  actions  are  those  which  establish  a value  for  the 
data  item  associated  with  the  decision  table.  All  of  the  other  data  items 
used  in  the  conditions  and  actions  are  the  ingredients.  Uhile  this  princi- 
ple restricts  somewhat  the  great  flexibility  of  decision  tables,  it  does 
lead  to  a desirable  consequence:  the  decision  tables  thus  formed  tend  to  be 
small  and  therefore  easy  to  formulate,  understand,  and  analyze. 

The  second  principle  is  that,  constants  and  operators  aside,  each  condition 
stub  and  action  stub  contains  only  data  items  defined  as  nodes  in  the 
information  network.  This  is  necessary  so  that  the  information  network  can 
serve  its  function  of  providing  access  to  all  the  necessary  data  items. 
This  principle  sounds  elementary;  however,  some  skill  is  required  in  formu- 
lating a standard  such  that  the  set  of  data  items  is  consistent.  Among  the 
errors  that  occur  are  omission  of  data  items,  use  of  multiple  names  for  the 
same  item,  and  use  of  the  same  name  for  different  items. 

As  an  example  of  the  formulation  of  conditions  and  actions  for  a decision 
table,  consider  another  sample  provision  taken  from  [15]  and  presented  in 
figure  3.1. 


The  provision  deals  entirely  with  the  evaluation  of  one  datum,  the  allow- 
able stress,  F(,.  There  are  four  ingredients,  variables  that  may  affect  the 
value  of  F(, : 

• the  yield  stress,  Fy| 

• the  width,  w; 

• the  thickness,  t;  and 

• the  type  of  member  (angle  strut  or  other  section) . 

The  step  by  step  procedure  for  formulation  of  a decision  table  is  flexible. 
One  approach  is  to  write  down  first  the  easily  identifiable  actions: 


1.  Fc  = 0.60  Fy 

2 . = given  by  formula  1 

3.  Fc  = 8,000/(w/t)2 


4.  Fc  .=  19.8  - 0.29  (w/t) 

5 . = given  by  formula  2 


Note  that  the 


fifth  action  was  found  in  a footnote 


of  the  cited  reference. 


From  a first  reading  of  the  provision,  it  is  clear  that  the  width- thickness 
ratio,  w/t,  is  very  important  and  that  several  conditions  will  involve  it. 
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3.2  Compression  of  Unstiffened  Elements 


Compression,  F^,,  in  kips  per  square  inch,  on  flat  unstiffened 
elements : 


(a)  For  w/t  < 63.3/7Fy:  F^,  = 0.60Fy 

(b)  For  63.3/7Fy  < w/t  < ^ 


Fc  = Fy [0.767  - (2.64/103)(w/t)7Fy] 


Formula  (1) 


(c)  For  144/7Fy  <w/t  <25:* 

= 8,000/(w/t)2 

(d)  For  25  < w/t  < 60:** 

For  angle  struts: 

Fc  = 8, 000/ (w/t) 2 
For  all  other  sections: 

F^  - 19.8  - 0.28 (w/t) 

In  the  above  formulas,  w/t  = flat-width  ratio  as  defined  in  section  2.2 


*When  the  yield  point  of  steel  is  less  than  33  ksi,  then  for  w/t 

ratios  between  63.3/7Fy  and  25: 


**Unstif fened  compression  elements  having  ratios  of  w/t  exceeding 
approximately  30  may  show  noticeable  distortion  of  the  free 
edges  under  allowable  compressive  stress  without  detriment  to  the 
ability  of  the  number  to  support  load. 

For  ratios  of  w/t  exceeding  approximately  60  distortion  of  the 
flanges  is  likely  to  be  so  pronounced  as  to  render  the  section 
structurally  undesirable  unless  load  and  stress  are  limited  to 
such  a degree  as  to  render  such  use  uneconomical. 


Fc  = 0.60Fy 


[w/t  - 63.3/7Fy](0.60Fy  - 12.8) 


Formula  (2) 


25(1  - 2.53/7Fy) 


Figure  3.1  Sample  provision 
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It  is  convenient  to  write  related  conditions  in  adjacent  positions,  as 
follows : 

1.  w/t  < 63.3/7Fy 

2.  w/t  < 144/7Fy 

3.  w/t  < 25 

4.  w/t  < 60 

5.  Member  type  = angle  strut 

The  next  step  in  the  preparation  of  the  table  is  to  begin  writing  the 
rules,  one  rule  at  a time.  The  process  is  iterative,  so  the  initial  order 
of  conditions  and  rules  is  not  of  paramount  importance.  The  first  three 
rules  are  easily  identified:  for  rule  one,  condition  one  is  true  and  the 

action  is  one;  for  rule  two,  condition  one  is  false,  condition  two  is  true, 
and  the  action  is  two;  for  rule  three,  condition  two  is  false,  condition 
three  is  true,  and  the  action  is  three.  Choosing  to  ignore  temporarily  the 
first  footnote,  rules  four  and  five  can  be  formulated:  for  both  rules, 

condition  three  is  false  and  condition  four  is  true;  condition  five  is  true 
for  rule  four  and  false  for  rule  five  while  rule  four  uses  action  three  and 
rule  five  uses  action  four. 

In  taking  account  of  the  first  footnote,  a new  rule  is  formed  which  in- 
volves a new  condition: 

6 . Fy  < 3 3 ks i 

For  the  sixth  rule  condition  one  is  false,  condition  three  is  true,  condi- 
tion six  is  true,  and  the  action  is  five.  The  decision  table  at  this  stage 
is  shown  in  table  3.5. 

At  this  point,  one  iteration  in  the  formulation  of  the  rules  is  complete. 
It  should  be  emphasized  that  the  blanks  in  the  condition  entry  do  not 
necessarily  represent  immaterial  entries,  because  no  consideration  has  been 
given  to  them  yet.  The  conditions  and  actions  can  be  seen  to  be  in  agree- 
ment with  the  stated  principles  of  formulation.  Completing  the  example 
will  not  add  to  the  study  of  conditions  and  actions,  but  it  is  instructive 
in  that  it  points  out  the  manner  in  which  decision  tables  demand  full 
consideration  of  the  situation  being  defined. 

For  rule  one,  condition  two  is  obviously  true  if  condition  one  is.  Condi- 
tions three  and  four  are  not  so  obvious.  A simple  calculation  indicates 
that  condition  three  can  be  false  when  condition  one  is  true  only  if 
Fy  < 6.4  ksi,  which  is  not  only  unlikely,  but  . impossible  if  the  material 
used  meets  the  ASTM  specifications  referenced  in  [15].  For  the  sake  of 
illustration,  this  information  will  be  ignored,  as  if  this  one  provision 
were  analyzed  in  isolation.  Therefore,  conditions  three  and  four  will  be 
immaterial  for  rule  one.  Conditions  five  and  six  also  turn  out  to  be 
immaterial  for  the  rule. 
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Table  3.5  Initial  condition  entries 


1 

2 

3 

4 

5 

6 

1 

w/t  < 63.3/7Fy 

T 

F 

F 

2 

w/t  < 144/7Fy 

T 

F 

3 

w/t  < 25 

T 

F 

F 

T 

4 

w/t  < 60 

T 

T 

5 

Member  strut  = angle  strut 

T 

F 

6 

Fy  < 33 

T 

1 

F^,  = 0.6  Fy 

X 

2 

Fj,  = formula  1 

X 

3 

Fc  = 8000/(w/t)2 

X 

X 

4 

F(,  = 19.8  - 0.28 (w/t) 

X 

5 

F(,  = formula  2 

X 

For  rule  two,  a similar  analysis  indicates  that  condition  three  could  be 
false  if  Fy  < 33  ksi.  Since  this  is  the  situation  defined  in  the  footnote 
and  covered  in  rule  six,  the  entry  for  conditions  three  and  four  is  true 
while  that  for  condition  six  is  false.  Condition  five  is  once  again  imma- 
terial . 

Rule  three  is  completed  using  reasoning  very  similar  to  that  for  rule  two. 
For  rules  four  and  five,  the  same  limited  analysis  that  was  invoked  on  rule 
one  is  used  again;  consequently,  the  entries  for  conditions  one,  two,  and 
six  are  immaterial  for  both  rules. 

For  rule  six,  condition  two  may  be  either  true  or  false  so  an  immaterial 
entry  is  made.  Condition  four  is  true  if  condition  three  is,  and  condition 
five  is  immaterial.  The  completed  table  is  shown  in  table  3.6. 

Analysis  of  this  table  will  show  that  rule  one  is  not  independent  of  either 
rule  four  or  rule  five.  It  can  be  determined  from  visual  examination  that 
the  same  set  of  condition  values  will  satisfy  rules  one  and  four  (for 
example:  T,  T,  F,  T,  T,  T),  and  that  another  set  can  be  found  for  rules 
one  and  five.  [A  much  easier  way  to  determine  this  is  to  attempt  to  gener- 
ate a decision  tree  (see  section  3.4)].  As  will  be  discussed  further  in 
the  following,  all  rules  in  a decision  table  must  be  independent,  there- 
fore, some  modification  of  the  table  is  necessary.  In  this  case,  the 
information  concerning  the  possible  range  of  values  for  Fy  must  be  taken 
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Table  3.6  Completed  condition  entries 


1 

2 

3 

4 

5 

6 

1 

w/t  < 63.3/7Fy 

T 

F 

F 

F 

2 

w/t  < 144/yFy 

T 

T 

F 

• 

• 

3 

w/t  < 25 

■■  T 

T 

F 

F 

T 

4 

w/t  < 60 

• 

T 

T 

T 

T 

T 

5 

Member  strut  = angle  strut 

• 

T 

F 

6 

Fy  < 33 

• 

F 

F 

T 

1 

Fc  = 0.6  Fy 

X 

2 

F^  = formula  1 

X 

3 

Fc  = 8000/(w/t)2 

X 

X 

4 

Fc  = 19.8  - 0.28 (w/t) 

X 

5 

Fj,  = formula  2 

X 

into  account.  As  pointed  out,  this  would  make  condition  three  true  for 
rule  one.  It  would  also  make  condition  one  false  for  rules  four  and  five. 
For  rule  one,  since  condition  three  is  true,  condition  four  will  be  true 
also.  The  revised  table  is  shown  in  table  3.7. 

This  completes  the  illustration  of  the  development  of  the  sample  decision 
table.  Decision  trees  derived  from  the  various  iterations  in  the  develop- 
ment are  shown  in  section  3.4. 

Contents  of  Condition  and  Action  Stubs.  Typically,  each  condition  stub 
consists  of  a single  condition  (true- false  comparison)  and  each  action 
consists  of  a single  assignment  expression  or  function.  Both  of  these 
simple  cases  can  be  extended. 

Several  logical  statements  may  be  combined  into  one  condition  with  the  use 
of  the  logical  functions  AND  and  OR.  Consider  the  hypothetical  condition 
"A>B  AND  C>D  AND  E>F."  The  condition  will  be  true  if  all  portions  of  the 
condition  are  true ,' but  it  will  be  false  if  any  one  portion  is  false.  If 
the  AND  operators  in  the  example  were  replaced  by  the  OR  operator,  the 
condition  would  then  be  true  if  any  one  portion  were  true,  and  it  would  be 
false  only  if  all  portions  were  false.  Many  provisions  in  standards  are 
conveniently  expressed  using  combined  conditions.  An  example  of  their  use 
is  included  at  the  end  of  this  section. 
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Table  3.7  Revised  condition  entries  (compare  table  3.6) 


1 

2 

3 

4 

5 

6 

1 

w/t  < 63.3/7Fy 

T 

F 

F 

F 

F 

F 

2 

w/t  < 144/7Fy 

T 

T 

F 

• 

• 

3 

w/t  < 25 

T 

■ T 

T 

F 

F 

T 

4 

w/t  < 60 

T 

T 

T 

T 

T 

T 

5 

Member  strut  = angle  strut 

• 

T 

F 

• 

6 

Fy  < 33 

F 

F 

• 

T 

1 

Ft  = 0.6  Fy 

X 

2 

Ft  =•  formula  1 

X 

3 

Ft  = 8000/(w/t)2 

X 

X 

4 

Ft  = 19.8  - 0.28 (w/t) 

X 

5 

Ft  = formula  2 

X 

Some  decisions  are  appropriate  to  perform  in  the  action  stubs.  As  an 
example,  consider  a provision  for  allowable  tension  stress  taken  from  [16] 
and  shown  in  figure  3.2.  The  decision  table  for  the  determination  of  the 
allowable  tension  stress  is  shown  in  table  3.8.  The  instruction  to  find 
the  minimum  or  maximum  of  a group  of  variables  is  conveniently  located  as 
part  of  the  action.  Note,  however,  that  logical  operations  included  in  the 
actions  are  not  included  in  the  decision  tree  or  in  any  of  the  checks  for 


On  the  net  section,  except  at  pin  holes: 

Ft  = 0.60Fy 

but  not  more  than  0.5  times  the  minimum  tensile  strength  of  the  steel. 

On  the  net  section  at  pin  holes  in  eyebars , pin-connected  plates  or 
built-up  members: 

Ft  - 0.45Fy 

For  tension  on  threaded  parts  see  Table  1.5. 2.1. 


Figure  3.2  Sample  provision 
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Table  3.8  Decision  table  with  compound  actions 


Location  = pinhole 

T 

F 

Ft  = 0.45  Fy 

X 

Ft  = min  (0.60  Fy,  0.50  F^) 

X 

independent  rules;  therefore  errors  in  their  formulation  are  more  difficult 
to  detect. 

The  style  of  defining  data  items  and  of  writing  conditions  and  actions  is 
an  important  consideration.  A tendency  exists  immediately  to  write  deci- 
sion tables  for  requirements  with  only  two  actions,  one  for  the  yes  value 
(satisfied)  and  one  for  the  no  value  (violated) . This  may  lead  to  decision 
tables  that  are  large  and  difficult  to  analyze.  When  the  analyst  finds 
that  a decision  table  is  large  (consisting  of  more  than  about  ten  rules), 
consideration  should  be  given  to  redefining  some  of  the  ingredients,  or  to 
partitioning  of  the  decision  table.  An  example  illustrating  this  point 
follows . 

Related  Conditions  and  Implicit  Entries.  Conditions  that  involve  the  same 
data  item  are  related.  In  many  cases,  the  value  for  one  condition  will 
predetermine  the  value  of  a related  condition.  Table  3.5  presents  such  a 
case  because  the  four  conditions  concerning  w/t  are  related  In  rule  one, 
the  first  condition  is  true;  therefore,  the  second  is  also  true  because  w/t 
cannot  be  both  less  than  63.3/7Fy  and  greater  than  144/7Fy.  (The  expansion 
of  the  entries  permitted  in  a limited  entry  table  allows  such  situation  to 
be  treated  to  advantage  [14]).  The  two  new  condition  entries  needed  to 
represent  related  conditions  are  implicitly  true  , , and  implicitly 
false,  They  are  used  when  the  value  of  a condition  for  a rule  is  pre- 
determined by  the  values  of  other  conditions  for  that  same  rule.  Thus, 
table  3.6  is  transformed  into  table  3.9. 

Besides  conditions  that  compare  a data  item  to  bounded  ranges,  there  are 
other  types  of  conditions  that  are  related.  A common  situation  in  stan- 
dards is  the  comparison  of  a data  item  to  the  elements  of  a Boolean  vector. 
The  conditions  concerning  the  type  of  electrodes  is  a mutually  exclusive 
set,  that  is,  only  one  of  them  may  be  used.  Therefore,  if  any  one  of  those 
four  conditions  is  true,  then  the  other  three  must  be  false.  Table  3.4  is 
rewritten  in  table  3.10  taking  account  of  the  mutually  exclusive  set  and  of 
the  relation  between  the  conditions  with  Fy  also. 

Some  sets  of  mutually  exclusive  conditions  have  another  property:  they  are 
collectively  exhaustive  (the  variable  always  takes  one  value  from  the  set) . 
When  both  properties  hold,  it  is  possible  to  write  a rule  in  two  equivalent 
ways  with  implicit  entries.  Consider  the  hypothetical  variable  x which 
must  take  a value  from  the  mutually  exclusive  and  collectively  exhaustive 
set  [A,  B,  C,  D] . The  three  rules  shown  in  table  3.11  are  equivalent. 
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1 

2 

3 

4 

5 

6 

1 

2 

3 

4 

5 


Table  3.9  Implicit  entries  (compare  table  3.6) 


1 2 3 4 5 6 


w/t 

< 63.3//Fy 

T 

F 

- 

- 

- 

F 

w/t 

< 144/VFy 

+ 

T 

F 

• 

w/t 

< 25 

+ 

+ 

T 

F 

F 

T 

w/t 

< 60 

+ 

+ 

+ 

T 

T 

+ 

Member  strut  = angle  strut 

• 

• 

T 

F 

Fy  < 

33 

F 

F 

• 

T 

Fc  = 

o 

o^ 

X 

Fc  = 

formula  1 

X 

Fc  = 

8000/(w/t)2 

X 

X 

Fc  = 

19.8  - 0.28 (w/t) 

X 

Fc  = 

formula  2 

X 

Table  3.10  Implicit  entries  (compare  table  3.4) 


Fy  < 36  ksi 

T 

F 

F 

- 

- 

Fy  < 50  ksi 

+ 

T 

T 

F 

F 

A233E60 

T 

T 

- 

- 

- 

A233E70 

- 

- 

T 

- 

- 

A316E70 

- 

- 

- 

T 

- 

A316E80 

- 

- 

- 

- 

T 

F^  = 13.6  ksi 

X 

X 

F.^  = 15.8  ksi 

X 

X 

F.^  = 17.7  ksi 

X 
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Table  3.11  Equivalent  rules 


12  3 


X = A 

F 

- 

F 

X = B 

T 

T 

+ 

X = C 

F 

- 

F. 

X = D 

F 

- 

F 

Note  that  the  set  of  electrode  designators  in  table  3.10  is  not  collec- 
tively exhaustive  because  there  are  many  more  types  of  electrodes.  It  is 
possible  that  they  could  be  made  collectively  exhaustive  if  another  deci- 
sion table  were  used  to  test  the  acceptability  of  the  electrodes;  the 
specification  is  not  complete  concerning  this  question  [15]. 

Uniqueness . A very  important  principle  in  the  theory  of  decision  tables  is 
that  one  rule  and  only  one  rule  must  be  matched  for  any  given  set  of  varia- 
bles that  are  used  to  define  the  conditions  [14].  That  is,  the  logical 
process  of  a decision  table  must  always  find  a unique  rule  in  any  possible 
situation.  Another  way  to  state  this  is  to  say  that  all  the  rules  in  a 
table  must  be  independent.  It  is  incorrect  for  any  two  rules  in  the  same 
table  to  have  identical  condition  entries.  When  two  rules  are  not  unique, 
they  are  called  dependent.  Note  that  two  rules  may  be  dependent  even 
though  their  condition  entries  are  not  identical  if  they  contain  immaterial 
or  implicit  entries.  This  was  demonstrated  in  the  discussion  of  table  3.6. 

If  two  rules  are  dependent  and  their  action  entries  are  the  same,  they  are 
called  redundant,  whereas  they  are  called  contradictory  if  their  action 
entries  are  different.  It  is  not  incorrect  for  two  different  rules  to  have 
the  same  action  entries.  In  some  cases,  two  such  rules  may  be  combined 
into  one.  If  two  rules  have  identical  entries  for  all  conditions  but  one 
and  have  the  same  action  entry  then  the  two  rules  can  be  made  into  one  by 
placing  an  immaterial  entry  at  the  condition  that  had  the  different  values . 
Note  that  the  different  values  in  the  two  original  rules  should  be  a true 
and  a false;  if  not,  one  or  both  of  the  rules  probably  contains  an  error. 

Completeness . One  benefit  that  can  be  derived  from  expressing  logic  in  a 
limited  entry  decision  table  format  is  that  it  is  possible  to  determine  if 
the  logic  is  complete.  A decision  table  is  complete  if  its  decision  tree 
contains  no  else  rules.  This  is  the  same  as  saying  that  a decision  table 
is  complete  when  its  condition  entries  contain  all  of  the  possible  combina- 
tions of  values  for  its  conditions.  Note  that  this  test  of  completeness 
does  not  consider  any  logic  contained  in  the  conditions. 

The  recommended  way  to  check  the  completeness  of  a decision  table  is  to 
generate  a decision  tree,  but  it  is  not  the  only  way.  A classical  way  of 
checking  the  completeness  of  decision  tables  is  to  count  the  equivalent 
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simple  rules  [14].  A simple  rule  is  one  that  contains  only  true  and  false 
entries.  A decision  table  with  n conditions  will  have  2^^  unique  simple 
rules.  Most  decision  tables  will  contain  entries  other  than  true  and 
false.  The  counting  procedure  is  easily  extended  to  those  with  immaterial 
entries.  Defining  a compound  rule  as  one  that  contains  an  immaterial 
entry,  a compound  rule  with  r immaterial  entries  represents  2^  equivalent 
simple  rules.  A decision  table  with  n conditions  is  complete  if  the  sum  of 
simple  rules --both  explicit  and  equivalent- - is  equal  to  2^  and  the  rules 
are  unique . 

Consider  table  3.12  (the  condition  entry  from  table  3.7).  The  last  two  rows 
are  tabulations  of  the  ntomber  of  immaterial  entries  and  of  equivalent 
simple  rules  for  each  of  the  rules  in  the  table.  The  total  number  of  simple 
rules  is  20,  much  less  than  2^  = 64,  so  the  decision  tree  should  contain 
else  rules,  which  it  does,  as  shown  in  figure  3.6  in  section  3.4,  Each  of 
the  else  rules  in  the  figure  can  be  considered  a compound  rule  with  immate- 
rial entries  for  those  conditions  not  included  on  their  path.  Thus,  the 
first  else  rule  does  not  test  conditions  five  and  six  so  it  represents  four 
equivalent  simple  rules.  Likewise,  the  second  else  rule  represents  eight 
equivalent  simple  rules  and  the  last  one  contains  32,  The  total  number  of 
simple  rules  shown  in  the  tree  is  the  sum  20  + 4 + 8 + 32  = 64,  which  is 
the  proper  total  for  a decision  table  with  6 conditions. 

An  instance  where  counting  simple  rules  in  a table  with  immaterial  entries 
can  lead  to  an  error  is  when  two  or  more  of  the  compound  rules  contain  the 
same  simple  rule.  This  error  will  not  occur  when  using  the  decision  tree 
approach  because  such  compound  rules  are  dependent  and  will  always  be 
identified  as  such.  If  the  rule  counting  method  is  used  to  check  complete- 
ness of  tables  with  immaterial  entries,  care  must  be  exercised  to  detect 
dependent  rules . 


Table  3.12  Counting  simple  rules 


1 

2 

3 

4 

5 

6 

Condition  1 

T 

F 

F 

F 

F 

F 

Condition  2 

T 

T 

F 

• 

• 

• 

Condition  3 

T 

T 

T 

F 

F 

T 

Condition  4 

T 

T 

T 

T 

T 

T 

Condition  5 

T 

F 

Condition  6 

F 

F 

• 

• 

T 

r 

2 

1 

1 

2 

2 

2 

2^^ 

4 

2 

2 

4 

4 

4 
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Implicit  entries  in  a table  make  the  counting  of  equivalent  simple  rules 
unreliable.  The  reason  is  that  it  is  not  predictable  (with  any  ease)  how 
many  simple  rules  a rule  with  implicit  entries  may  represent. 

As  previously  stated,  the  recommended  procedure  for  checking  the  complete- 
ness of  a decision  table  is  to  use  the  decision  tree  to  locate  else  rules. 
All  of  the  else  rules,  that  is,  any  rule  not  included  in  the  original 
table,  will  be  detected  using  the  decision  tree.  The  condition  entries  for 
an  else  rule  can  be  found  by  tracing  along  the  path  from  the  else  rule  to 
the  start  of  the  tree,  taking  the  condition  entry  from  the  sense  of  the 
branch.  Any  condition  not  encountered  on  the  path  will  have  an  immaterial 
entry.  Note  that  implicit  entries  can  not  be  detected  from  the  decision 
tree.  Once  all  the  else  rules  have  been  found,  each  should  be  examined  to 
determine  why  it  was  not  anticipated  in  the  original  table. 

Generally  speaking,  decision  tables  for  standards  should  be  complete, 
because  an  else  rule  indicates  an  error  situation.  Some  tables  may  be 
formulated  using  an  else  rule  to  lead  to  a specific  action.  For  example, 
rules  5 through  10  in  table  3.13  in  the  next  section  could  be  replaced  with 
one  else  rule  leading  to  action  two.  However,  it  is  recommended  that  this 
approach  not  be  used  by  the  analyst  until  all  of  the  rules  have  been  exam- 
ined. Once  this  is  accomplished,  the  else  rule  may  be  a convenient  short- 
hand. 

One  exception  to  this  completeness -checking  procedure  can  occur  when  tables 
have  implicit  entries.  It  is  possible  to  generate  an  else  rule  in  the 
decision  tree  which  is  opposite  to  the  implicit  entry  in  some  stated  rule. 
These  else  rules  do  not  make  the  table  incomplete. 

Style  of  Table.  Previously,  it  was  pointed  out  that  the  manner  of  defining 
data  items  and  writing  actions  has  a bearing  on  the  complexity  of  the 
decision  tables  produced.  One  example  from  a model  building  code  [1]  will 
be  used  to  illustrate  this.  The  provision  of  interest  is  included  in 
section  1411.0  of  the  code  and  is  shown  in  figure  3.3.  This  section  in- 
cludes provisions  for  sign  materials,  bottom  clearance,  maximum  height,  and 
support  materials.  For  the  purpose  of  this  analysis,  bottom  clearance  has 
been  included  in  the  provision  for  maximum  height. 

A decision  table  was  written  for  checking  the  provision  for  the  maximum 
height,  with  two  possible  actions  (1)  height  acceptable  and  (2)  height  not 
acceptable.  The  decision  table  appears  in  table  3.13  and  involved  a signi- 
ficant amount  of  preparation.  Note,  among  other  things,  that  conditions  3 
and  4 are  mutually  exclusive  but  not  collectively  exhaustive,  and  that 
bottom  clearance  has  been  made  condition  1 in  this  table  rather  than  a 
separate  provision. 

Table  3.13  is  logically  complete  but  complex.  Introduction  of  a new  data 
item  called  "Maximum  allowable  height"  leads  to  a substantial  simplifica- 
tion using  two  decision  tables  instead  of  one,  as  shown  in  table  3.14. 

The  revised  set  of  tables  involves  fewer  decisions  and  is  less  subject  to 
misinterpretation. 
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Section  1411,0  Roof  Signs 

1411.1  Materials:  All  roof  signs  shall  be  constructed  entirely  of 

metal  or  other  approved  noncombustible  materials  except  as  provided  in 
section  1409.5.  Provision  shall  be  made  for  electric  ground  of  all 
metallic  parts;  and  where  combustible  materials  are  permitted  in 
letters  or  ther  ornamental  features,  all  wiring  and  tubing  shall  be 
kept  free  and  insulated  therefrom. 

1411.2  Bottom  Clearance:  There  shall  be  a clear  space  of  not  less 

than  six  (6)  feet  between  the  lowest  part  of  the  sign  and  the  roof 
level  except  for  necesssary  structural  supports. 

1411.3  Closed  Signs:  A closed  roof  sign  shall  not  be  erected  to  a 

height  greater  than  fifty  (50)  feet  above  fireproof  and  noncombustible 
buildings  (types  1 and  2)  nor  more  than  thirty-five  (35)  feet  above 
the  roof  of  non- fireproof  (type  3)  buildings. 

1411.4  Open  Signs:  An  open  roof  sign  shall  not  exceed  a height  of 

one  hundred  (100)  feet  above  roof  of  buildings  of  fireproof  and 
noncombustible  construction,  (type  1 and  2);  and  not  more  than  sixty 
(60)  feet  above  the  roof  of  buildings  of  non- fireproof  (type  3) 
construction. 

1411.5  Combustible  Supports:  Within  Fire  Districts  Nos.  1 and  2,  no 

roof  sign  which  exceeds  forty  (40)  feet  in  height  shall  be  supported  on 
or  braced  to  wooden  beams  or  other  combustible  construction  of  a build- 
ing or  structure  unless  otherwise  approved  by  the  building  official. 


Figure  3.3  Sample  provisions 
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Table  3.13  First  approach  to  checking  maximum  height 


123456789  10 


Clearance  < 6' 

T 

T 

T 

T 

T 

T 

T 

T 

T 

F 

Sign  const.  = closed 

T 

T 

F 

F 

T 

T 

F 

F 

Bldg. 

type  = 1 or  2 

T 

- 

T 

- 

T 

- 

T 

- 

F 

Bldg. 

type  ■=  3 

- 

T 

- 

T 

- 

T 

- 

T 

F 

• 

Height 

> 35' 

• 

F 

• 

• 

- 

T 

+ 

+ 

Height 

> 50' 

F 

- 

• 

• 

T 

• 

+ 

+ 

• 

Height 

> 60' 

- 

- 

F 

• 

+ 

T 

Height 

> 100' 

- 

- 

F 

- 

T 

Height 

acceptable 

X 

X 

X 

X 

Height 

not  acceptable 

X 

X 

X 

X 

X 

X 
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Table  3.14  Second  approach  to  checking  maximum  height 


1 

2 

3 

4 

5 

6 

1 

Clearance  < 6' 

F 

T 

T 

T 

T 

T 

2 

Sign  const.  = closed 

• 

• 

T 

T 

F 

F 

3 

Bldg,  type  = 1 or  2 

• 

F 

" 

T 

- 

T 

4 

Bldg,  type  =■  3 

F 

T 

- 

T 

- 

1 

Max.  height  = 0' 

X 

X 

2 

Max.  height  = 35' 

X 

3 

Max.  height  = 50' 

X 

4 

Max.  height  = 60' 

X 

5 

Max.  height  = 100' 

X 

Height  < max.  height 

T 

F 

Height  acceptable 

X 

Height  not  acceptable 

X 
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623.31  Dimensions:  Stairs  shall  be  at  least  twenty- two  (22)  inches 

wide  with  risers  not  more  and  treads  not  less  than  eight  (8)  inches 
and  landings  at  foot  of  stairs  not  less  than  forty  (40)  inches  wide  by 
thirty- six  (36)  inches  long,  located  not  more  than  eight  (8)  inches 
below  the  access  window  or  door. 


Figure  3.4  Sample  provision 


Combined  Conditions.  It  was  stated  previously  that  conditions  may  be 
composed  of  compound  logical  statements,  and  that  use  of  such  conditions  is 
frequently  advantageous  in  that  the  number  of  rules  is  reduced.  Another 
provision  taken  from  a model  building  code  [1]  and  shown  in  figure  3.4 
illustrates  this.  It  should  be  clear  from  the  language  of  this  provision 
that  only  one  compound  logical  statement  is  required  in  the  condition  stub. 
The  resulting  decision  table  is  shown  in  table  3.15. 

3.3.2  Proper  Usage 

Many  of  the  suggestions  for  proper  use  have  been  introduced  in  narrative 
form  in  section  3.3.1  and  will  be  summarized  here. 

Table  size.  It  is  best  to  restrict  tables  to  manageable  size,  of  the  order 
of  10  rules  at  most.  Tables  much  larger  than  that  tend  to  be  difficult  to 
formulate  and  analyze . 

Completeness  of  stubs.  The  first  step  in  analyzing  a provision  should  be 
the  complete  listing  of  all  possible  conditions  and  actions,  as  illustrated 
in  section  3.3.1.  This  discipline  is  most  helpful  in  subsequent  analysis; 
it  is  also  an  early  indication  that  the  table  may  be  too  large,  and  that 
the  provision  could  fruitfully  be  subdivided  into  several  smaller  tables. 


Table  3 . 15  Compound  conditions 

1 2 


Stair  width  > 22" 

AND 

T 

F 

Riser  < 8" 

AND 

Tread  > 8" 

AND 

Landing  width  > 40" 

AND 

Landing  length  > 36" 

AND 

Landing  below  access 

0<x<8" 

Dimensions  acceptable 

X 

Dimensions  not  acceptable 

X 
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Top-down  development.  As  an  alternative  to  the  above  recommendation,  one 
may  begin  to  analyze  requirements  in  a top-down  fashion  by  recognizing  that 
a requirement  may  have  only  two  actions:  requirement  satisfied  or  require- 
ment violated.  Attention  can  then  focus  on  the  conditions.  Again,  if  too 
many  conditions  are  involved,  the  requirement  provision  may  be  subdivided 
into  one  table  for  the  requirement  itself,  and  one  or  more  sub  tables  for 
the  key  ingredients. 

Incremental  development.  Once  the  conditions  and  actions  are  identified,  a 
good  strategy  to  follow  is  first  to  identify  only  those  condition  entries 
that  represent  directly  the  statements  in  the  original  provision,  leaving 
all  other  entries  as  immaterial.  Then,  interaction  among  rules  and  tests 
for  uniqueness  can  be  examined  by  generating  a tree , and  immaterial  entries 
modified  to  implicit  entries  as  needed  on  succeeding  iterations. 

Compound  conditions . As  illustrated  in  section  3.3.1,  individual  condi- 
tions occurring  together  may  be  combined  into  compound  conditions  using 
logical  connectives  of  AND  and  OR. 

Compound  actions . The  evaluation  of  both  requirements  and  determinations 
frequently  involves  selecting  the  minimum  or  the  maximum  of  several  expres- 
sions. As  illustrated  by  table  3.8,  such  "subsidiary"  tests  can  be  handled 
in  the  action  stub  by  conditionals.  However,  as  discussed  in  connection 
with  that  table,  such  conditionals  are  "buried"  in  the  stub,  and  are  not 
available  for  testing.  Also,  such  "buried"  provisions  are  not  available  for 
classification  purposes:  in  the  example  shown,  one  cannot  attach  separate 
classifiers  to  the  two  expressions  to  indicate  that  one  guards  against 
failure  by  yielding  while  the  other  pertains  to  rupture. 

Boolean  vectors.  Examples  such  as  table  3.10  illustrate  the  point  made  in 
section  3.1.3  that  many  conditions  involve  testing  a Boolean  vector  vari- 
able against  one  of  its  possible  values. 

Identification  of  ineredients . SASE  at  present  does  not  analyze  the  con- 
tents of  the  condition  and  action  stubs.  Thus,  it  is  the  analyst's  respon- 
sibility to  ensure  that  all  elements  of  the  condition  and  action  stubs 
other  than  constants  and  operators  are  defined  data  items,  representing  the 
ingredients  of  the  datum  generated  by  the  decision  table.  Consistent  with 
the  top-down  development  sketched  above,  the  analyst  may  develop  the  table 
first  and  then  use  it  to  ADD  the  INGREDIENTS  of  the  DATUM  represented  by 
the  table. 

3.3.3  Representation 

Each  decision  table  is  represented  in  SASE  by  a TABLE  entity. 

A table  is  referenced  by  the  REFERENCE  number  of  its  corresponding  data 
item  (see  section  3.1.3).  To  establish  the  cross-reference  between  the 
datum  and  the  table,  when  the  ENTER  TABLE  command  is  given,  the  attributes 
of  the  datum  are  automatically  set  as  follows: 

• SOURCE  is  set  to  DERIVED;  and 
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• TYPE  is  set  to  TABLE 


The  attributes  of  a table  entity  are  its  CONDITIONS,  ACTIONS  and  RULES,  and 
COMMENT . 

Since  in  SASE,  actions  can  only  produce  alternative  values  for  the  data 
item  represented  by  the  table,  it  follows  that  each  rule  can  have  only  one 
action  entry.  Thus,  SASE  uses  a condensed  form  for  the  input  of  action 
entries.  Table  3.16  repeats  shows  the  action  entry  portion  of  table  3.5, 
each  action  corresponding  to  a different  assignment  of  F^,.  The  action  entry 
form  used  in  SASE  is  shown  in  table  3.17. 

SASE  permits  two  modes  for  entering  tables:  by  row  (conditions  followed  by 

actions)  or  by  columns  (rules) . 

In  the  row- entry  mode,  conditions  are  entered  in  the  following  order: 

• a sequential  condition  number  starting  with  1; 

• an  optional  condition  stub  entered  as  a text  string; 

• the  separation  symbol  ; 

• the  condition  entries,  separated  by  blanks,  each  entry  one  of  the 
symbols : 

T or  Y for  yes  or  true  (the  symbols  are  equivalent) 

F or  N for  no  or  false  (the  symbols  are  equivalent) 

+ for  implicit  yes 

for  implicit  no 

. or  I for  immaterial  (the  symbols  are  equivalent) 

The  keyword  CONDITIONS  is  given  at  the  beginning  of  the  first  condition  row 
and  either  CONDITIONS  or  the  repetition  symbol  is  given  at  the 

beginning  of  each  succeeding  row.  A dollar  sign  "$"  at  the  end  of  a line 
signifies  continuation. 

SASE  accepts  the  number  of  entries  in  the  first  condition  row  as  the  number 

of  rules  in  the  table,  and  expects  all  succeeding  rows  to  have  the  same 

number  of  entries. 

To  complete  the  row-entry  mode,  actions  are  entered  in  the  following  order: 

• a sequential  action  number  starting  with  1; 

• an  optional  action  stub  entered  as  a text  string; 

• the  separation  symbol  ; 

t 

• a list  of  the  rule  (column)  number(s)  which  result  in  this  action, 
as  shown  in  table  3.17,  separated  by  commas. 
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Table  3.16  Standard  form  of  rule  entry 


Rules 


1 2 3 4 5 6 


Action  1 

X 

2 

X 

3 

X 

X 

4 

X 

5 

X 

Table  3.17  Condensed  form  of  action  entry 

Rules 

1 2 3 4 5 6 


Actions 

1 

2 

3 

3 

4 

5 
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The  key  word  ACTIONS  is  given  at  the  beginning  of  the  first  action  row,  and 
either  ACTIONS  or  the  repetition  symbol  for  each  succeeding  row.  A 

dollar  sign  "$"  at  the  end  of  a line  signifies  continuation. 

The  keyword  END  completes  the  entry  of  the  decision  table. 

In  the  column- entry  mode,  rules  are  entered  in  the  following  order: 

• a ^sequential  rule  number  starting  with,  1; 

• the  condition  entries,  as  above; 

• the  separation  symbol  ; 

• an  action  number  for  the  action  corresponding  to  this  rule. 

The  keyword  RULES  is  given  at  the  beginning  of  the  first  rule,  and  either 
RULES  or  the  repetition  symbol  for  each  succeeding  column.  A dollar 

sign  "$"  at  the  end  of  a line  signifies  continuation. 

Again,  the  keyword  END  completes  the  entry  of  the  decision  table. 

Note  that  condition  and  action  stubs  cannot  be  ENTERed  in  the  RULES  form  of 
input;  they  must  be  ADDed  subsequently. 

SASE  accepts  the  niomber  of  condition  entries  in  the  first  rule  as  the 
number  of  conditions,  and  expects  all  succeeding  columns  to  have  the  same 
ntimber  of  condition  entries.  Similarly,  SASE  accepts  the  highest  action 
number  in  any  one  rule  column  to  be  the  number  of  actions. 

Once  a table  has  been  ENTERed,  stubs  and  condition  and  action  entries  may 
be  ADDed,  MODIFYed  and  DELETEd.  Furthermore,  additional  conditions,  ac- 
tions, and  rules  may  be  ADDed  sequentially  to  the  existing  ones.  Finally, 
an  ELSE  rule  may  be  ADDed  to  the  existing  rule. 

The  conditions,  actions,  and  rules  may  also  be  arbitrarily  RESEQUENCEd. 

In  its  present  version,  SASE  treats  condition  and  action  stubs  as  text, 
i.e.,  it  performs  no  analysis  of  any  kind.  Subsequent  versions  of  SASE  may 
include  additional  processing  capabilities,  i.e.,  identification  of  ingre- 
dient data  items  from  the  stubs  or  direct  generation  of  executable  computer 
programs  [17]. 

3 . 4 Decision  trees 

3.4.1  Definition 

The  logic  contained  in  a decision  table  can  be  expressed  as  a decision 
tree,  which  is  a network  with  one  condition  at  each  node.  The  branches 
from  each  node  represent  the  possible  condition  entries  and  the  termination 
of  each  path,  or  limb,  is  a rule.  Figure  3.5  gives  an  example  of  a deci- 
sion tree  generated  from  a hypothetical  decision  table. 
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Cl 

C2 

C3 


R1  R2  R3  R4 


C2 

C3 


T T T F 
T T F • 
T F • • 


(a)  Decision  tree  showing  the  subtables  produced  for  each  condition  tested. 


(b)  Decision  tree  alone. 


Figure  3.5  Decision  tree  generation 
from  a hypothetical  decision  table. 
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The  process  of  generating  a decision  tree  from  a decision  table  can  be 
summarized  by  the  following  steps  [20]: 

1.  Begin  with  the  original  table  (the  condition  entry  is  all  that  is 
necessary) . 

2.  Select  a condition  to  test.  Table  3.18  provides  rules  for 
condition  selection  that  result  in  an  efficient  decision  tree. 

3.  i-Produce  two  subtables.  Each  will  contain  the  remaining  conditions 
not  yet  tested.  One  will  contain  those  rules  for  which  the  tested 
condition  is  true,  the  other  those  rules  for  which  it  is  false.  A 
rule  with  an  immaterial  entry  will  be  in  both  new  subtables. 

4.  If  the  new  subtable  contains  at  least  one  condition  and  more  than 
one  rule,  go  to  step  2 and  repeat  the  cycle;  else,  go  to  step  5. 

5.  There  are  four  possibilities  at  this  stage: 

• The  subtable  contains  exactly  one  rule  and  no  conditions  except 
those  with  immaterial  entries.  The  rule  has  been  isolated,  so 
the  path  is  ended. 

• The  subtable  contains  one  rule  and  at  least  one  condition  with 
a true  or  false  entry.  Return  to  step  2 and  continue. 


Table  3.18  Rules  for  selecting  a condition  for  testing 


1 

One  condition  has  fewest  immaterial  entries 

T 

- 

- 

2 

One  of  the  conditions  tied  for  fewest  immaterial 
entries  has  fewest  implicit  entries 

T 

- 

- 

3 

Quick  rule  desired 

• 

T 

- 

4 

Delayed  rule  desired 

• 

- 

T 

1 

Select  condition  with  fewest  immaterial  entries 

X 

2 

Select  condition  with  fewest  implicit  entries 

X 

3 

Select  condition  tied  for  fewest  immaterial  and 
fewest  implicit  entries  that  has  greatest 
difference  between  number  of  true  and  false  entries 

X 

4 

Select  condition  tied  for  fewest  immaterial  and 
fewest  implicit  entries  that  has  least  difference 
between  number  of  true  and  false  entries 

X 
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• The  subtable  contains  no  rules.  The  rule  isolated  was  not  in- 
cluded in  the  original  table.  The  union  of  all  such  rules  is 
called  the  else  rule. 

• The  subtable  contains  no  remaining  conditions,  but  does  contain 
two  or  more  rules.  The  rules  are  not  independent;  that  is, 
they  can  be  satisfied  by  the  same  set  of  condition  entries. 
The  remaining  rules  are  either  redundant  or  contradictory. 

The  expression  of  logic  in  a decision  tree  strongly  resembles  a conven- 
tional flow  chart. 

Note  that  more  than  one  network  can  be  generated  from  any  decision  table, 
depending  on  the  order  of  selection  of  the  conditions  for  testing,  but  that 
a unique  set  of  condition  entries  will  always  isolate  the  same  rule. 
Decision  trees  can  be  generated  from  extended  entry  tables  also;  however, 
the  number  of  branches  leaving  each  node  depends  on  the  number  of  unique 
entries  for  the  condition.  One  of  the  advantages  of  a limited  entry  table 
is  that  the  decision  tree  will  always  have  two  branches  coming  out  of  each 
condition  node. 

The  decision  tree  derived  from  table  3.7  is  shown  in  figure  3.6.  There  are 
three  else  rules  identified;  that  is,  rules  that  are  not  in  the  table. 
Examination  of  the  entries  for  condition  four  in  table  3.7  shows  that  the 
false  entry  is  never  used;  this  is  pointed  out  in  the  decision  tree  by  the 
existence  of  only  an  else  rule  on  the  false  branch  from  condition  four. 
The  second  footnote  in  the  original  provision  pertains  to  that  situation, 
but  no  specific  disposition  is  made  (a  limitation  on  w/t  of  60  does  exist 
elsewhere  in  the  specification.) 

When  implicit  entries  are  encountered  in  the  decomposition  of  a table  into 
a decision  tree,  the  same  steps  described  above  are  followed.  The  implicit 
entries  are  treated  somewhat  differently  than  explicit  or  immaterial  en- 
tries. First,  it  is  efficient  to  avoid  testing  conditions  with  implicit 
entries,  similar  to  the  efficiency  gained  in  the  avoidance  of  immaterial 
entries.  However,  the  avoiding  of  immaterial  entries  takes  precedence  over 
implicit  entries.  When  new  subtables  are  formed  by  separating  the  true 
rules  and  false  rules  for  the  condition  being  tested,  the  implicit  entries 
are  used  like  explicit  entries  to  determine  the  subtable  for  a rule.  For 
example,  a rule  with  a for  the  condition  being  tested  is  entered  in  the 

subtable  of  true  rules,  but  not  in  the  subtable  of  false  rules.  When  a 
subtable  contains  only  one  rule,  the  implicit  entries  are  treated  as  imma- 
terial entries.  That  is,  they  need  not  be  tested  to  verify  the  rule. 

The  decision  tree  generated  from  table  3.9  is  shown  in  figure  3.7.  Compare 
it  to  the  decision  tree  shown  in  figure  3.6:  it  is  much  more  compact  since 

fewer  conditions  need  be  tested.  In  addition,  two  of  the  else  rules  that 
appear  in  figure  3.6  but  represent  impossible  situations  have  disappeared 
in  figure  3.7. 
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C4  + + + Cl  + + + C2  + + + C3  -^  + + R1 

- - - - ELSE 
- - - - ELSE 

- ■■-■■■  C3  + + + C6  + + + R6 

- - - - C2  + + + R2 

- - - - R3 

. . . . C5  + + + R4 


- - - - ELSE 


- R5 


Figure  3.6  Decision  tree  in  SASE  format  generated 
from  Table  3.7  ( "+”  denotes  branch  corresponding  to 
true  value  of  condition  tested,  to  false  value). 


Figure  3.7  Decision  tree  in  SASE  format  generated  from  table  3.9. 
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Implicit  entries  make  a tremendous  difference  in  the  number  of  else  rules 
encountered  in  the  decision  tree.  Compare  the  two  decision  trees  derived 
from  tables  3.4  and  3.10,  shown  in  figures  3.8a  and  3.8b.  The  former  has 
15  else  rules  while  the  later  has  three.  The  else  rules  in  figure  3.8b 
represent  possible  combinations  of  material  strengths  and  electrode  types 
that  are  not  included  in  the  decision  table  because  nothing  was  said  about 
them  in  the  table  in  the  original  specification.  The  question  arises  from 
this  analysis  as  to  whether  the  electrodes  listed  with  the  various  material 
strengths  are  the  only  ones  permitted  for  use.  This  question  can  be 
resolved  only  by  consultation  with  the  experts  who  wrote  the  specification. 

3.4.2  Proper  Use 

Generate  early  and  often.  While  decision  tables  are  convenient  and  compact 
representation  of  the  logic  of  provisions,  decision  trees  are  the  best  tool 
for  checking  tables  for  uniqueness,  completeness  and,  to  a lesser  degree, 
clarity.  Therefore,  a decision  tree  should  be  generated  and  analyzed  as 
soon  as  a skeleton  decision  table  is  formed,  and  the  tree  re-generated  and 
examined  whenever  the  table  is  significantly  modified. 

Corrections . If  the  analysis  reveals  two  or  more  redundant  rules,  the 
table  should  be  carefully  examined.  Two  redundant  rules  should  differ  by  a 
true  and  false  entry  for  one  condition;  if  that  is  the  case,  the  two  can  be 
combined  into  a single  rule  with  an  immaterial  entry;  if  not,  then  one  or 
both  rules  must  be  in  error.  If  two  contradictory  rules  are  found,  the 
action  entry  may  be  in  error,  or  the  logic  may  be  at  fault,  probably  be- 
cause one  or  more  immaterial  entries  are  improperly  used. 

Use  of  ELSE.  Most  decision  tables  representing  provisions  of  standards  are 
highly  incomplete,  in  that  the  number  of  actual  rules  is  considerably  less 
than  the  number  of  possible  combinations  of  conditions.  The  ELSE  qualifier 
should  be  used  to  generate  the  rules  not  defined  in  the  table.  Each  ELSE 
rule  should  be  carefully  analyzed  to  determine  whether  it  represents: 

• a combination  that  is  impossible  because  of  related  conditions; 

• an  omission  from  the  original  standard  that  must  be  rectified;  or 

• a combination  that  falls  outside  the  scope  of  the  standard. 

3.4.3  Representation 

In  SASE,  decision  trees  are  generated  by  the  GENERATE  TREE  command.  A 
decision  tree  is  referenced  by  the  reference  number  of  the  decision  table 
or,  more  precisely,  of  the  datum  derived  by  the  decision  tree. 

The  GENERATE  TREE  command  has  a number  of  optional  qualifiers  that  control 
the  processing. 

ORDER  specifies  the  sequence  in  which  condition  rows  are  selected  for 
testing:  INPUT  specifies  that  conditions  are  to  be  tested  in  the  original 
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cl  + + + C2  + + + C3  + + + C4  + + + ELSE 


- 

- - - - C5  + + + ELSE 

- 

- - - - C6  H-  + + ELSE 

- - - . - else 

- - ELSE  - - - - R1 

- - - -C3+++C2+++C4+++  ELSE 


- 

- - - - C5  + + + ELSE 

- 

- - C6  + + + ELSE 

. „ 

- - ELSE  - - - - R2 

(a.)  - - - - C2  + + + C4  + + + C5  + + + ELSE 


- 

- . _ . _ (36  + + + ELSE 

- 

- - - - R3 

- 

- - - - ELSE 

- - 

- - C4  + + + ELSE 

- - - - C5  + + + C6  + + + ELSE 

C2  + + + Cl  + + + C3  + + + R1 

- - - - R4 

- - - - ELSE 

- - - - C6+++  R5 

- . - . C3  + + + R2 

- - - - ELSE 

- - - - C4  + + + R3 


- - - - C5  + + + R4 

- - ELSE 

- - - - C6  + + + R5 

(b)  ...  - else 


Figure  3.8  Comparision  of  decision  trees  in  SASE  format 
generated  from  (a)  table  3.4  and  (b)  table  3.10. 
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input  sequence,  while  QUICK  or  DELAY  specify  the  test  sequences  discussed 
below. 

The  specific  algorithm  operates  as  follows: 

• first  priority:  find  the  condition  row  with  the  minimum  number  of 

immaterial  entries  or  "I"). 

• second  priority:  find  the  condition  row  with  the  maximum  number  of 

explicit  entries  ("T",  "Y" , "N" , or  "F"). 

• third  priority: 

for  the  QUICK  rule  algorithm,  find  the  condition  with  maximum 
difference  between  the  number  of  true  ("T"  or  "Y")  and  false 
("F"  or  "N")  entries. 

for  the  DELAY  rule  algorithm,  find  the  condition  with  minimum 
difference  between  the  number  of  true  ("T"  or  "Y")  and  false 
("F”  or  "N")  entries. 

The  ELSE  qualifier  causes  all  ELSE  rules  to  be  generated  and  added  to  the 
defined  rules . 

The  SORT  qualifier  rearranges  the  tree  and  the  corresponding  table  so  that 
shorter  branches  of  the  tree  are  displayed  before  the  longer  branches. 

The  algorithm  produces  an  error  message  if: 

• any  redundant  rules  are  detected  (i.e.,  rules  are  not  unique  and 
their  action  entries  are  the  same) ; or 

• any  contradictory  rules  are  detected  (i.e.,  rules  are  not  unique 
but  their  action  entries  are  different) . 

When  either  of  these  errors  occur,  no  tree  is  generated.  The  user  must 
MODIFY  the  original  decision  table  and  re-execute  the  GENERATE  TREE  com- 
mand, 

3 . 5 Functions 
3.5.1  Definition 

Not  all  provisions  depend  upon  conditions  for  their  evaluation.  A provi- 
sion which  does  not  require  the  evaluation  of  any  conditions  (i.e.,  leads 
to  a "degenerate"  decision  table  with  only  one  rule  and  one  action)  is 
called  a function. 

Functions  have  been  classified  in  [8]  as 
» definite  functions; 
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• indefinite  functions;  and 

• implied  functions. 

A definite  function  provides  a specific,  unambiguous  means  for  deriving  the 
value  of  a dependent  data  item.  The  most  common  means  are  formulae  or 
tables . 

An  indefinite  function  specifies  a set  of  ingredients  for  the  evaluation  of 
a derived  data  item,  but  does  not  specify  precisely  how  the  ingredients  are 
to  be  used  in  the  evaluation.  An  illustration  is  taken  from  section  4.2.2 
of  [18] . 

"4.2.2  Period  Determination 

The  fundamental  period  of  the  building,  T,  (used)  in  formula  4-2 
may  be  determined  based  on  the  properties  of  the  seismic  resist- 
ing system  in  the  direction  being  analyzed  and  the  use  of  estab- 
lished methods  of  mechanics  assuming  the  base  of  the  building  to 
be  fixed  ..." 

In  this  instance  the  datum  "Calculated  fundamental  period"  is  said  to  be  an 
indefinite  function  of  the  following  ingredients: 

• Period  calculated  using  established  methods 

• Properties  of  seismic  resisting  system  in  direction  being  analyzed 

• Building  assumed  to  be  fixed  at  base 

An  implied  function  is  used  to  denote  instances  in  which  the  provision  of  a 
standard  seems  to  indicate  a precedence  relation  between  data  items,  but 
the  analyst  must  make  some  assumption  as  to  what  that  relation  is.  Some- 
times the  assumption  is  so  strongly  implied  that  the  ingredience  relation 
can  be  treated  just  as  was  the  indefinite  function  described  previously. 
However,  the  implication  may  be  weak  or  nonexistent.  Such  instances  are 
called  assumed  functions.  Two  examples  illustrate  the  typical  characteris- 
tics of  such  provisions. 

The  first  is  a sentence  from  section  7.2.1  of  [18]; 

"The  strength  of  foundation  components  shall  not  be  less  than 
that  required  for  forces  acting  without  seismic  forces." 

It  is  assumed  that  the  "forces  acting  without  seismic  forces"  include  all 
other  forces  that  are  included  in  [18].  Thus  the  data  item,  "Required 
strength  without  seismic  load"  is  said  to  be  an  assumed  function  of  the 
ingredients : 

• Dead  load  effect 

• Live  load  effect 
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• Snow  load  effect 


The  second  example  is  from  section  1.2  of  [18]: 

"These  provisions  establish  requirements  for  strengthening  of 
existing  buildings  where  alterations  reducing  the  seismic  force 
resistance  are  made  ..." 

Among  the  data  items  identified  in  the  provision  is:  "Seismic  force  resis- 

tance before  proposed  activity."  It  is  assumed  that  this  resistance  should 
be  determined  according  to  the  provisions  of  the  remaining  chapters,  how- 
ever, no  data  items  can  be  identified  as  specific  ingredients. 

3.5.2  Proper  Use 

Identification  of  ingredients.  SASE  at  present  does  not  perform  any  analy- 
sis of  the  body  of  functions.  Therefore,  it  is  entirely  the  analyst's 
responsibility  to  identify  the  ingredients  of  the  datum  generated  by  the 
function. 

Clarification  of  function  type.  The  analyst  should  ask  the  drafting  com- 
mittee to  clarify  the  type  of  function  used,  and  attempt  to  have  the  com- 
mittee eliminate  as  many  of  the  indefinite  and  implied  functions  as  possi- 
ble. In  many  instances,  it  is  not  appropriate  to  have  a definite  function 
appear  in  the  standard  itself  (e.g.,  the  ingredient  "period  calculated  with 
the  use  of  established  methods  of  mechanics"  in  the  first  example  in  sec- 
tion 3.5.1);  in  such  cases,  the  commentary  to  the  standard  may  be  an  appro- 
priate medium  to  describe  or  reference  the  applicable  function. 

Expansion  to  decision  table.  Many  determinations  that  appear  to  be  func- 
tions on  first  reading  may  turn  out  to  be  decision  tables  when  footnotes, 
exceptions,  etc.  are  also  included.  In  such  cases,  the  FUNCTION  must  be 
DELETEd  and  a new  TABLE  ENTERed. 

3.5.3  Representation 

Each  function  is  represented  in  SASE  by  a function  entity  or  record. 

A function  is  referenced  by  the  REFERENCE  number  of  its  corresponding  data 
item  (see  section  3.1.3).  As  with  decision  tables,  when  the  ENTER  FUNCTION 
REFERENCE  in  command  is  given,  the  attributes  of  the  datum  are  set  as 
follows : 

• SOURCE  is  set  to  DERIVED 

• TYPE  is  set  to  FUNCTION 

The  only  attribute  of  a FUNCTION  entity  is  its  BODY,  entered  as  a text 
string. 
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3 . 6 Networks 


3.6.1  Definition 

General . A network  can  be  defined  as  a set  of  points  connected  by  lines. 
The  points  are  called  nodes  and  the  lines  are  called  branches.  A branch 
may  only  be  connected  to  two  nodes,  one  at  each  end,  and  branches  may  only 
be  connected  at  nodes,  although  they  may  cross  over  one  another  at  points 
without  impairing  the  generality  of  the  definition  [3]. 

The  information  network  used  to  represent  the  precedence  relations  of  the 
information  contained  in  a standard  is  formed  by  assigning  one  data  item  to 
each  node.  These  nodes  may  be:  numerical  quantities  such  as  material 

strength;  qualitative  values  such  as  the  type  of  occupancy  of  a building; 
or  Boolean  values  such  as  the  status  of  a requirement  (satisfied  or  unsat- 
isfied) . In  order  to  provide  a more  concise  representation  of  the  rela- 
tions among  data  items,  each  detailed  decision  table  or  function  is  ab- 
stracted into  a subnetwork,  or  subtree,  consisting  of: 

1.  a node  representing  the  derived  item  generated  by  the  table  or 
function; 

2.  nodes  representing  all  the  data  items  occurring  in  the  table  or 
function,  i.e.,  the  ingredients;  and 

3.  directed  branches  from  each  ingredient  to  the  node  representing 
the  derived  data  item. 

The  nodes  in  set  (2)  are  called  the  (direct)  ingredients  of  node  (1) ; con- 
versely, node  (1)  is  called  a (direct)  dependent  of  all  nodes  in  set  (2). 

Each  decision  table  establishes  the  value  for  one  data  item,  so  each  deci- 
sion table  is  uniquely  associated  with  a node  in  the  network.  Some  nodes 
represent  items  that  have  their  value  established  by  a function;  in  such 
cases  the  function  is  associated  with  the  node  as  if  it  were  a decision 
table . 

There  will  be  data  items  that  have  no  procedure  for  evaluation  contained 
within  the  standard.  The  nodes  for  these  items  are  called  input  nodes 
because  their  value  must  be  supplied  by  sources  of  information  outside  the 
standard. 

Construction  of  the  Network.  The  global  network  can  be  assembled  by  inter- 
connecting the  subtrees  representing  the  individual  provisions.  Provisions 
leading  to  an  illustrative  network  are  shown  in  figure  3.9,  which  is  a 
simplification  of  the  provisions  for  the  design  of  simply  reinforced  beams 
taken  from  [2]. 

The  network  is  shown  in  figure  3.10. 

In  this  network,  we  can  trace  out  the  global  dependence  of  a node,  that  is, 
all  data  items  affected  by  the  datum.  By  following  the  branches  in  the 
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Figure  3.9  Simplified  provisions  for  the 
design  of  simply  reinforced  concrete  beams. 
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Figure  3.10  Information  network  for  simplified  provisions 
for  the  design  of  simply  reinforced  concrete  beams. 
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reverse  direction,  we  can  trace  out  the  global  ingredience  of  a node,  that 
is,  all  data  items  needed  to  evaluate  the  datum.  We  can  also  classify  the 
nodes  into: 

• input  data  items,  that  is,  nodes  without  ingredients; 

• derived  data  items,  that  is,  nodes  with  one  or  more  ingredients; 
and 

• output  data  items , that  is , nodes  with  no  dependents . 

The  input  nodes  will  have  no  ingredients.  All  of  the  nodes  that  have 
ingredients  are  called  derived  nodes . The  information  network  does  not 
show  how  they  are  derived;  it  shows  only  the  data  items  that  may  be  neces- 
sary in  order  to  derive  the  value.  Some  of  the  nodes  (at  least  one)  will 
have  no  dependents;  they  are  called  terminal  or  output  nodes  of  the  net- 
work, The  output  nodes  represent  the  requirements  included  within  the 
standard.  The  concept  of  using  the  requirement  as  the  output  node  is 
rather  arbitrary,  since  one  final  node  could  be  defined  as  "standard  satis- 
fied". However,  this  would  be  an  ambiguous,  cumulative  requirement.  It  is 
advantageous  to  truncate  the  network  at  some  convenient  definition  of 
requirements  in  order  to  provide  freedom  in  the  use  of  the  organizational 
network,  as  is  discussed  in  chapter  4. 

Characteristics  of  the  Network.  One  of  the  characteristics  of  the  informa- 
tion network  that  can  be  used  to  advantage  in  the  formulation  and  expres- 
sion of  standards  is  its  concise  representation  of  all  the  information 
contained  in  the  standard.  The  simple  process  of  defining  a consistent  set 
of  items  of  information  can  lead  to  the  identification  of  extraneous  items. 
When  an  existing  standard  is  being  analyzed  or  restructured,  a preliminary 
list  of  the  items  of  information  would  be  one  of  the  first  steps  in  the 
analysis.  Ingredients  do  not  become  apparent  until  the  examination  of  the 
detailed  logic  involving  each  data  item  is  begun.  The  study  of  the  de- 
tailed logic  is  described  in  section  3.3  on  decision  table  analysis. 

Once  the  network  is  constructed  from  the  list  of  nodes  and  their  ingre- 
dients, it  is  possible  to  discern  global  ingredience  and  dependence  proper- 
ties of  the  hierarchy  of  information.  The  global  ingredience  of  a particu- 
lar node  is  the  portion  of  the  overall  network  located  on  branches  pointing 
towards  the  node:  it  is  a subnetwork  that  begins  at  the  node  in  question, 
then  goes  to  each  of  its  ingredients , which  are  followed  in  turn  by  each  of 
their  ingredients  in  a recursive  manner  until  all  of  the  branches  end  at 
input  nodes.  The  direction  of  traversing  this  network  is  counter  to  the 
direction  of  the  branches.  The  global  dependence  is  constructed  in  a 
similar  manner,  except  dependents  are  used:  the  final  nodes  are  the  output 
nodes,  and  the  direction  of  traversing  is  in  the  direction  of  the  branches 
as  defined  originally.  In  summary,  the  global  ingredience  shows  all  of  the 
nodes  that  may  have  a direct  or  indirect  effect  on  the  node  in  question. 
The  global  dependence  shows  all  of  the  nodes  that  may  be  affected  by  the 
node  in  question. 
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Computations  on  the  Information  Network.  A number  of  useful  computations 
can  be  performed  on  a network.  The  network  can  be  viewed  as  a critical- 
path-method  (CPM)  diagram  with  all  branches  having  a length  of  one  unit. 
Labelling  the  terminal  (output)  node  0,  the  labels  of  all  nodes  are  deter- 
mined as : 

L°]^  = max  (L°j  -i-  1) 

where  j ranges  over  the  set  of  direct  dependents  of  node  k.  The  cor- 
responding labels  are  shown  on  figure  3.11,  and  represent  the  highest  or 
latest  level  from  output  of  each  node. 

Alternatively,  the  input  nodes  are  labelled  0,  and  the  labels  of  all  nodes 
determined  as: 

= max  (L^j  +1) 

where  j ranges  over  the  set  of  direct  ingredients  of  node  k.  The  cor- 
responding labels  are  shown  on  figure  3.12  and  represent  the  highest  level 
from  input  of  each  node. 

Finally,  to  complete  the  CPM  analogy,  the  float  of  every  node  is  calculated 
as : 


^k  “ ^aax  ■ (^^k  ^°k^ 


where 

Ljjjax  maximum  label  in  network 

= longest  path  from  input  to  output 

The  various  quantities  for  the  sample  network  are  tabulated  in  table  3.19 
below. 

The  input  level,  output  level,  and  float  are  three  properties  of  the  nodes 
in  a network  that  are  of  considerable  use  in  the  expression  of  a standard, 
as  discussed  below. 

Connectedness . Information  networks  frequently  will  have  more  than  one 
node  at  the  output  level.  It  is  entirely  possible  that  the  information 
network  for  a standard  will  consist  of  more  than  one  completely  separate 
network,  although  this  possibility  seems  improbable.  Such  cases  do  not 
alter  the  generality  of  what  has  been  described.  The  definition  of  what 
constitutes  an  output  mode  is  somewhat  arbitrary,  as  discussed  previously. 

Acyclic  Networks.  Information  networks  will  generally  have  many  closed 
loops  or  cycles,  although  none  of  them  may  be  traversed  completely  without 
going  counter  to  the  direction  of  at  least  one  branch.  Such  a network  is 
called  acyclic.  If  it  were  possible  to  traverse  a complete  loop  in  the 
direction  of  the  branches,  it  would  mean  that  a node  might  require  assign- 
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Figure  3.11  Information  network  ordered 
by  levels  from  output  data  item. 
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Figure  3.12  Information  network  ordered 
by  levels  from  input  data  items. 


73 


Table  3.19  Levels  and  floats  in  example  network 


Node 

Level  from  Output 

Level  from  Input 

Float 

TROK 

0 

4 

0 

M 

1 

0 

3 

Mu 

1 

3 

0 

Pb 

1 

■ 2 

1 

q 

2 

2 

0 

0 

2 

0 

2 

^1 

2 

1 

1 

p 

3 

1 

0 

fy 

3 

0 

1 

^ C 

3 

0 

1 

b 

4 

0 

0 

d 

4 

0 

0 

^s 

4 

0 

0 

ment  of  its  value  before  it  could  be  evaluated.  While  iterative  calculation 
is  used' in  many  analyses,  it  is  not  appropriate  in  standards.  When  such  a 
situation  is  encountered,  it  will  be  necessary  to  define  two  nodes  as  the 
initial  and  final  values  of  a datum  to  break  the  loop. 

Use  in  Formulation.  Most  of  the  uses  of  the  information  network  in  aiding 
the  formulation  of  a standard  are  qualitative.  One  exception  is  the  check 
that  the  network  be  acyclic,  which  can  be  detected  explicitly  in  the  con- 
struction of  the  network.  Other  explicit  checks  are  that  the  network  must 
have  at  least  one  output  node  and  one  input  node.  Disconnected  portions  of 
the  network  should  be  examined  critically.  When  the  disconnected  portion 
consists  of  one  node,  an  error  in  formulation  is  revealed.  The  node  either 
has  some  ingredients  that  were  left  out,  is  an  overlooked  ingredient  of 
some  other  node,  or  is  not  used  at  all. 

The  information  network  also  allows  the  explicit  determination  of  the 
global  ingredience  and  global  dependence  of  a node  as  described  above. 
When  a change  in  the  definition  (decision  table)  of  a node  is  contemplated, 
the  dependent  network  allows  the  effects  of  that  change  to  be  traced 
through  the  specification.  Likewise  the  ingredience  network  allows  any 
subset  of  the  specification  to  be  checked  for  consistency. 

One  qualitative  check  is  that  provisions  dealing  with  parallel  situations 
should  be  located  at  approximately  the  same  level  from  output.  The  compar- 
ison of  output  levels  is  based  on  the  concept  that  provisions  described  by 
a nearly  identical  set  of  arguments  (i.e.,  classifiers)  should  have  nearly 
identical  global  dependence  networks. 

Another  qualitative  check  is  on  the  similarity  of  ingredients  for  various 
nodes.  Particularly  when  reformulation  of  an  existing  standard  is  being 
pursued,  it  may  be  possible  to  combine  several  similar  provisions  taken 
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from  different  portions  of  the  standard  into  one  new  provision,  thus  clari- 
fying the  intent  of  the  provision. 

Use  in  Expression.  The  information  network  is  of  use  in  composing  the 
textual  expression  of  a standard  by  providing  a guide  to  the  ordering  of 
data  items  required  for  the  definition  of  a set  of  related  provisions  and 
in  the  recognition  of  cross  references.  The  overall  organization  of  the 
text  (ordering  of  sets  of  provisions)  is  somewhat  independent  of  the  infor- 
mation network  and  is  discussed  in  the  chapter,  on  outlining. 

Two  schemes  may  be  defined  for  the  ordering  of  the  data  items  used  in  the 
written  expression  of  a set  of  provisions  represented  by  an  information 
network:  conditional  and  direct  [12,  13]. 

In  the  conditional  or  top-down  strategy,  we  list  the  top  node  first,  fol- 
lowed by  its  direct  ingredients,  that  is,  those  at  level  1 from  output. 
Each  of  these,  in  turn,  is  listed  with  its  direct  ingredients,  etc.  The 
skeletal  structure  of  the  text  for  the  sample  network  shown  in  figure  3.10 
may  read  as  follows: 

Tension  reinforcement  shall  satisfy  the  following  . . . 

is  evaluated  as  follows  . . . 

q is  evaluated  as  follows  . . . 

p is  evaluated  as  follows  . . . 

p|j  is  evaluated  as  follows  . . . 

k]_  is  evaluated  as  follows  ... 

(the  input  data  items  are  not  shown). 

Comparison  of  the  skeletal  structure  with  figure  3.10  will  show  that  the 
structure  represents  a particular  path  through  the  graph  information  net- 
work. The  order  in  which  the  paths  are  traversed  is  immaterial,  and  will 
depend  on  the  analyst's  preference.  What  is  important  is  that: 

• every  complete  outline  represents  a spanning  tree  (that  is,  it 
contains  every  node)  of  the  network,  rooted  at  the  terminal  node; 
and 

• branches  of  the  network  not  included  in  the  outline  may  be  repre- 
sented as  cross-references  to  other  nodes. 

In  the  direct  or  bottom-up  strategy,  we  list  the  input  nodes  first,  fol- 
lowed by  their  direct  dependents,  that  is,  those  at  level  1 from  input. 
Each  of  these,  in  turn,  is  listed  with  its  direct  dependents,  etc.  The 
skeletal  structure  may  read  as  follows: 

Given  b,  d,  and  Ag ' compute  p as  follows  . . . 
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Given  p,  fy  and  fj,'  compute  q . . . 

Compute  k]_  . . . 

Compute  . . . 

Compute  p-j^  . . . 

Evaluate  whether  tension  reinforcement  requirement  is  satisfied. 

Again,  the  writer  has  the  option  of  ordering  the  nodes  in  one  level,  but 
the  two  properties  discussed  for  the  conditional  strategy  still  hold:  the 
outline  is  a spanning  tree,  and  all  cross-references  point  to  nodes  pre- 
vious defined. 

Direct  ordering  will  lead  to  a boring  style  of  writing  when  the  global 
ingredience  of  a provision  is  several  levels  deep,  because  the  reader  is 
forced  to  read  the  definition  of  all  the  possible  ingredients  before  the 
provision  is  located.  Conditional  ordering  allows  the  user  familiar  with 
the  standard  to  cease  reading  the  text  of  a set  of  provisions  when  he  has 
read  the  first  statement,  if  he  is  already  aware  of  the  definition  of  items 
close  to  input,  or  if  he  is  only  scanning  the  major  requirements. 

The  global  ingredience  network  alone  is  not  sufficient  for  organization  of 
the  textual  expression  needed  to  define  a set  of  provisions.  One  diffi- 
culty is  that  it  does  not  indicate  which  of  the  several  nodes  at  a given 
precedence  level  should  be  used  first.  The  problem  cannot  be  completely 
separated  from  the  logic  expressed  in  the  decision  tables.  The  float  and 
output  level  may  be  of  some  aid.  They  are  simple  numerical  indicators  of 
the  depth  of  precedence,  or  numbers  of  intermediate  steps  between  the  input 
and  output  node  and  the  node  in  question.  Ingredients  that  have  the 
largest  float  or  level  will  generally  have  the  smallest  global  ingredience 
networks  and  thus  will  be  easier  to  define.  In  some  cases,  it  will  be  most 
convenient  to  order  the  ingredients  that  are  defined  in  the  simplest  manner 
first;  however,  no  consistent  rule  concerning  this  has  been  developed. 

Another  benefit  that  the  information  network  offers  for  formulation  and 
expression  of  standards  is  the  explicit  recognition  of  cross-references. 
Frequently,  input  parameters  and  derived  data  are  used  in  the  evaluation  of 
more  than  one  provision.  Proper  cross-referencing  depends  on  the  recogni- 
tion of  these  reuses  of  the  same  data  items.  This  becomes  more  important 
in  larger  standards  because  cross-referenced  nodes  will  sometimes  have  a 
large  global  ingredience  of  their  own.  Cross-referencing  is  necessary  to 
prevent  presentation  of  duplicative  material  and  possible  confusion. 

3.6.2  Proper  Use 

Proceed  from  small  to  bie.  It  is  best  to  generate  and  analyze  smaller 
networks  corresponding  to  individual  chapters  before  combining  the  data 
items  into  larger  networks  for  several  chapters. 
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Corrections  for  loons.  If  the  analysis  reveals  the  presence  of  loops, 
these  must  be  eliminated.  Loops  may  result  from: 

• "circular"  definitions,  where  a data  item  is  in  its  own  global 
ingredience  network.  Such  data  items  must  be  redefined  and  the 
ingredients  modified  accordingly; 

• iterative  calculations,  involving  a trial  and  error  procedure. 
Such  procedures  are  not  appropriate  for  a standard;  if  absolutely 

^needed,  two  data  items  must  be  defined,  e.g.,  one  for  the  assumed 
and  one  for  the  computed  value  of  the  datum  in  question,  where  the 
assumed  value  is  treated  as  an  input  data  item; 

• overly  strict  interpretation  of  some  cumulative  requirements  (see 
section  3.3)  or  indefinite  functions  (see  section  3.5).  Once  ident- 
ified, these  items  must  be  reinterpreteted. 

Detached  subnetworks . Detached  subnetworks  should  be  examined  with  care. 
It  will  frequently  happen  that  subnetworks  corresponding  to  individual 
chapters  will  have  several  detached  subnetworks,  to  be  "connected"  later 
through  cross-references  between  chapters.  This  is  a valid  occurrence  of 
detached  subnetworks.  By  contrast,  an  undesirable  situation  is  one  where 
the  detached  subnetwork  is  within  the  scope  of  the  chapter,  but  there  is  no 
"logical"  way  to  interconnect  it  with  the  remainder  of  the  chapter  through 
compound  requirements . 

Choice  of  SORT.  The  SORT  qualifier  determines  the  ordering  of  nodes  in  a 
subsequent  DISPLAY  of  the  network  (see  the  next  section) . No  firm  rules  can 
be  given  on  the  choice  of  the  SORT  qualifier.  Generally  SMALL  SMALL  should 
be  tried  first:  it  will  put  shorter  paths  ahead  of  longer  ones. 

3.6.3  Representation 

In  SASE,  a network  is  generated  by  the  GENERATE  NETWORK  command.  In  the 
present  implementation  of  SASE,  there  can  be  only  one  network  for  each 
VERSION  of  a standard.  Therefore,  the  network  is  not  given  an  explicit 
reference  number.  The  user  must  specify  the  CHAPTERS  of  the  version  to  be 
included  in  the  network. 

In  SASE  the  network  can  be  DISPLAYed  as  a spanning  tree,  that  is,  a tree 
containing  all  of  the  nodes  in  the  network.  Each  branch  of  the  tree  corre- 
sponds to  a path  through  the  network.  The  SORT  qualifier  controls  the  order 
in  which  nodes  appear  in  the  tree.  If  the  SORT  qualifier  is  used,  either 
FLOAT  or  LEVEL  may  be  specified  as  the  primary  key;  the  other  will  be  taken 
as  the  secondary  key.  The  first  SMALL  or  LARGE  qualifier  indicates  sorting 
on  the  primary  key  in  descending  or  ascending  order,  respectively.  The 
second  SMALL  or  LARGE  qualifier  indicates  the  sorting  order  for  the  second- 
ary key. 

SASE  produces  an  error  message  if  a loop  is  detected,  and  prints  out  the 
list  of  nodes  (data  item  reference  numbers)  constituting  the  loop.  The 
user  must  modify  the  INGREDIENTS  of  one  or  more  data  items  to  break  the 
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loop  before  the  network  can  be  generated.  SASE  does  not  generate  any  error 
messages  if  disconnected  subnetworks  are  encountered. 

The  DISPLAY  NETWORK  command  provides  two  basic  options  for  displaying  the 
network: 

• If  INGREDIENCE  or  DEPENDENCE  is  specified,  a spanning  tree  is  dis- 
played, indented  by  levels;  either  the  ENTIRE  network  or  a subnet- 
work rooted  at  a specified  node  may  be  requested. 

• If  DATALIST  is  specified,  a tabular  display  of  data  items  is  pro- 
duced, including  the  LEVEL  and  FLOAT  attributes  of  each  data  item. 
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4.  ORGANIZING  THE  INFORMATION  OF  A STANDARD 


The  organization  of  a standard  deals  with  both  the  scope  (the  range  of 
subject  matter)  and  the  arrangement  (the  grouping  and  ordering)  of  the 
provisions  it  contains.  An  effective  organizational  system  assists  the 
writers  of  a standard  in  defining  its  scope  and  assists  the  user  of  a 
standard  in  quickly  and  reliably  finding  the  relevant  provisions.  This 
chapter  presents  the  SASE  techniques  for  dealing  with  the  organization  of  a 
standard.  Major  sections  are:  Classifiers,  Hierarchy,  Scopelist,  Index, 

Organization,  and  Outline. 

4 . 1 Classifiers 

4.1.1  Definition 

Classifiers  are  words  that  concisely  define  the  scope  of  a provision.  All 
provisions  that  are  requirements  should  be  classified  for  the  purpose  of 
generating  organizations  and  outlines;  frequently,  key  provisions  that  are 
determinations  also  are  classified,  at  least  for  indexing  purposes. 

As  discussed  in  section  3.2,  a requirement  contains  at  least  two  basic 
components.  The  subject  of  the  requirement  may  be  a physical  entity,  pro- 
cess or  participant,  collectively  these  are  referred  to  as  THING  in  the 
following.  The  predicate  of  the  requirement  defines  the  REQUIRED  QUALITY 
of  the  subject.  Classifiers  serve  to  identify,  relate,  and  organize  the 
subjects  and  the  predicates. 

Faceted  Classification  System.  The  SASE  methodology  for  classification  of 
provisions  of  standards  is  based  on  the  faceted  classification  system 
developed  for  library  science.  The  essence  of  a faceted  classification  can 
be  reduced  to  three  features; 

1.  The  classification  consists  of  several  more  or  less  independent 
areas,  called  fields  and  facets.  A field  can  be  thought  of  as  a 
subject  area  (such  as  architecture)  and  a facet  can  be  thought  of 
as  a way  to  classify  within  a particular  field  (a  classification 
of  architectural  objects  might  have  facets  for  material,  histori- 
cal period,  form,  etc.). 

2.  Each  facet  is  structured  hierarchically  and  may  have  several 
levels . 

3.  Rules  are  provided  for  combining  terms  from  different  facets  for 
the  classification  of  an  entire  standard. 

Within  a facet,  the  classifiers  should  be  logically  structured,  that  is, 
the  classifiers  should  be: 

1.  mutually  exclusive  at  every  level  of  the  hierarchy  to  guarantee 
that  each  provision  is  uniquely  described  by  one  set  of  classi- 
fiers only, 
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2.  collectively  exhaustive  at  every  level  to  ensure  complete  cover- 
age , and 

3.  strict  subdivisions  of  the  parent  classifier  in  the  hierarchy. 

Development  of  a Classification  System.  There  are  five  important  princi- 
ples that  govern  the  development  of  a faceted  classification  system  for  the 
provisions  of  a standard: 

1.  There  must  be  at  least  two  independent  fields:  one  for  THING  and 

one  for  REQUIRED  QUALITY  of  the  provisions  (see  section  3.2). 
Relevant  classification  of  requirements  requires  this  as  a mini- 
mum. There  also  may  be  independent  fields  for  determinations. 
The  fact  that  the  fields  are  independent  facilitates  the  construc- 
tion of  a classification  and  allows  great  freedom  in  constructing 
alternative  arrangements . 

2.  Each  facet  must  be  a strictly  logical  tree.  That  is,  each  suc- 

ceeding level  must  be  a direct  subdivision  of  the  parent  and  the 
logical  principles  of  mutual  exclusion  and  collective  exhaustion 
must  be  satisfied  at  each  level.  This  logical  rigor  is  not  typi- 
cal of  faceted  classification  systems,  but  it  is  required  of  the 
classification  system  of  a standard  in  order  to  satisfy  two  of  the 
objectives  of  organization:  uniqueness  and  completeness  (see 

section  4.6). 

3.  A field  may  have  any  number  of  facets,  and  each  facet,  except  the 
root  facet,  must  be  a logical  subdivision  of  some  other  classifier 
in  the  field.  In  order  to  provide  an  outline  that  is  unique, 
complete,  and  graded  (see  section  4.6),  it  must  be  possible  to 
combine  the  facets  in  at  least  one  way  to  produce  a single  logical 
tree  for  the  entire  field.  Thus  the  potential  connections  between 
facets  must  be  stated  explicitly.  A corollary  of  this  principle 
along  with  the  first  principle  suggests  that  the  same  facet  not  be 
used  in  more  than  one  field. 

4.  The  maximum  number  of  siblings  (classifiers  having  the  same  parent 
classifier)  at  any  level  should  not  exceed  a reasonable  estimate 
of  the  span  of  immediate  memory  of  the  user,  of  the  order  of  five 
to  ten. 

5.  The  facets  should  promote  an  even  division  of  the  scope  of  the 
standard. 

The  third  principle  merits  additional  discussion.  One  use  of  the  classifi- 
cation system  is  to  build  an  outline,  which  should  follow  the  logical 
principles  as  much  as  possible.  Thus,  it  is  desirable  to  avoid  the  possi- 
bility of  a tree  containing  siblings  that  are  not  mutually  exclusive  and  it 
is  necessary  to  avoid  any  closed  meshes.  Non-exclusive  siblings  is  the 
more  substantive  concern  because  closed  meshes  rarely  arise  in  practice. 
The  first  concern  is  satisfied  by  allowing  only  one  facet  to  be  appended  to 
any  one  classifier. 
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Consider  the  example  taken  from  [18]  shown  in  figure  4.1. 

Two  of  the  three  facets  in  figure  4.1a  apply  to  the  classifier  "Building 
Part,"  which  is  a terminal  classifier  of  another  facet  (not  shown).  The 
third  facet  applies  only  to  the  combination  of  the  classifiers  "Seismic 
resisting"  and  "Component."  As  is  frequently  the  situation,  it  is  neces- 
sary to  be  able  to  subdivide  a single  classifier  (Building  Part)  into  more 
than  one  facet.  To  accomplish  this  logically the  subdivisions  are  applied 
successively  rather  than  concurrently.  Thus,  the  second  facet  is  applied 
to  thei^terminal  classifiers  of  the  first  facet,  as  shown  in  the  left  column 
of  figure  4.1b.  The  right  column  of  figure  4.1b  shows  a variation  that 
maintains  logical  rigor  but  it  does  so  by  dividing  the  facet  "Function  of 
Building  Part"  into  subfacets.  This  subdivision  of  facets  is  quite  useful 
in  constructing  outlines,  and  will  be  discussed  further. 


Function  of  building  part 

Scale  of  building  part 

Structural 

System 

Seismic  resisting 

Component 

Non-seismic  resisting 
Foundation 

Material 

Nonstructural 

Type  of  seismic  resisting  component 
Frame 

Shear  panel 

a)  Three  logical  facets, 

shown  in  indented  outline  format 

(Function  of  building  part) 

(Function  of  building  part) 

Structural 

Struc tural 

Seismic  resisting 

System 

System 

Seismic  resisting 

Component 

Non-seismic  resisting 

Frame 

Foundation 

Shear  panel 

Component 

Material 

Seismic  resisting 

Non-seismic  resisting 

Frame 

System 

Shear  panel 

Component 

Non-seismic  resisting 

Material 

Foundation 

Foundation 

Material 

Nonstructural 

Nonstructural 

b)  Two  possible  ways  of  combining  the  three  facets  into  a tree 

Figure  4.1  Sample  combinations  of  facets  of  subject  classifiers 
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The  example  shows  several  other  interesting  features.  Note  that  the  name 
of  the  facet  disappears  when  it  is  appended  to  another  classifier.  In  this 
sense,  the  name  of  a facet  is  transparent.  Also  note  that  facets  need  not 
be  appended  at  all  possible  locations -- "Scale  of  building  part"  is  not  ap- 
pended to  "Foundation"  in  the  left  column  of  figure  4.1b,  and  the  second 
level  subfacet  of  "Function  of  building  part"  is  not  appended  to  "Material" 
in  the  right  column  of  figure  4.1b.  In  addition,  a single  facet  may  require 
the  context  of  presence  (or  absence)  of  several  other  classifiers  to  be 
relevant- - "Type  of  seismic  resisting  component"  is  attached  to  only  those 
branches  in  figure  4.1b  containing  the  classifiers  "seismic  resisting"  and 
"components."  Techniques  for  combining  facets  are  discussed  in  more  detail 
in  the  description  of  outlining  methods  in  section  4.6. 

The  division  of  the  facet  "Function  of  building  part"  shown  in  figure  4.1b 
illustrates  that  the  fundamental  unit  of  the  classification  is  a single  set 
of  sibling  classifiers  connected  to  their  parent  classifier.  This  unit  is 
the  smallest  unit  that  preserves  the  logical  principles;  hereafter  it  is 
termed  a nuclear  tree.  For  purposes  of  combining  classifiers  into  an 
outline,  a facet  may  be  divided  into  its  constituent  nuclear  trees.  Thus 
the  logical  structure  of  a classification  system  may  be  summarized  as 
follows ; 

1.  A nuclear  tree  is  the  smallest  logical  unit. 

2.  A facet  consists  of  one  or  more  nuclear  trees  and  is  the  largest 
logical  unit.  It  may  be  subdivided  into  smaller  logical  units  at 
any  time. 

3.  A field  consists  of  one  or  more  facets  and  does  not  necessarily 
maintain  logical  rigor.  Each  field  is  considered  to  be  an  inde- 
pendent classification. 

It  is  important  that  any  deviation  from  the  above  logical  principles  be 
soundly  based,  and  that  the  classification  still  give  an  unambiguous  indi- 
cation of  the  applicability  of  a particular  requirement  to  a particular 
classifier.  The  logical  principles  can  be  relaxed  when  classifying  for  the 
purpose  of  indexing,  but  it  is  more  convenient  to  treat  this  subject  in  the 
principles  for  classing  provisions. 

In  addition  to  following  the  principles  just  presented,  care  must  be  taken 
to  provide  relevant  and  progressive  ordering  of  the  classification. 

Classing  Provisions.  There  are  five  principles  pertinent  to  the  associa- 
tion of  classifiers  and  provisions,  that  is,  to  the  assignment  of  arguments 
to  data  items.  These  principles  are: 

1.  Each  requirement  must  be  classed  according  to  THING  and  to 
REQUIRED  QUALITY. 

2.  No  provision  may  be  classed  by  more  than  one  classifier  from  any 
one  facet. 


82 


3.  Each  classifier  associated  with  a provision  must  be  the  most  de- 
tailed that  includes  the  scope  of  the  provision. 

4.  All  terminal  classifiers  must  be  associated  with  at  least  one 
provision. 

5.  It  is  permissible  to  establish  a priority  among  the  classifiers 
associated  with  a provision. 

The  first  principle  assures  relevance  based  on  the  model  of  the  underlying 
structure  of  requirements.  No  comparable  model  or  principle  exists  for 
determinations . 

The  second  and  third  principles  are  simply  corollaries  of  the  logical 
principles.  It  frequently  is  useful  to  violate  both  of  them  when  classing 
for  the  purposes  of  indexing.  Consider  a provision  that  applies  to  both 
the  "Seismic  resisting"  and  "Foundation"  parts  of  the  "Structure",  but  not 
to  the  "Non-seismic  resisting"  parts  (refer  to  the  first  facet  in  figure 
4.1a).  Outlining  has  the  function  of  finding  a single  best  location  in  a 
linear  list  for  a provision.  Thus,  according  to  the  logical  principles, 
the  provision  must  be  classed  as  "Structure".  Indexing  has  the  function  of 
directing  a user  to  a provision  from  any  relevant  starting  point,  thus  the 
provision  is  most  appropriately  classed  "Seismic  resisting"  and  "Founda- 
tion." It  is  fairly  simple  to  account  for  different  ways  of  classing  the 
same  provision  and  to  call  on  the  appropriate  classification  for  a given 
purpose . 

The  fourth  principle  prevents  useless  detail  in  the  classification  system. 

The  fifth  principle  is  useful  in  outlining.  In  the  light  of  the  basic 
structure  of  classification,  it  appears  that  such  a priority  will  be  of  the 
most  use  when  applied  to  classifiers  from  different  facets  in  the  same 
field.  Thus  a provision  classed  as  "Structure",  "System",  and  "Seismic 
resisting"  from  the  facets  in  figure  4.1a  (with  the  first  facet  subdivided 
as  previously  described)  might  be  more  appropriately  placed  in  one  or  the 
other  outlines  of  figure  4.1b  based  on  the  priority  given  to  "System"  and 
"Seismic  resisting." 

Basic  Categories.  The  establishment  of  a set  of  basic  categories  gives  a 
firm  starting  point  for  the  development  of  a classification  for  a parti- 
cular standard.  In  this  section,  categories  appropriate  for  use  in  design 
standards  for  buildings  are  proposed,  with  some  discussion  of  their  impor- 
tance, application,  and  interrelationships.  It  is  expected  that  the  same 
or  similar  categories  would  be  appropriate  for  standards  that  pertain  to 
other  subjects  or  that  are  broader  in  scope  than  building  design.  The 
objective  in  presenting  these  categories  is  to  provide  an  aid  for  the 
development  of  a relevant  and  meaningful  classification.  They  should  be 
reviewed  for  any  specific  application.  The  indiscriminate  application  of 
these  or  any  other  basic  categories  is  unwise. 
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The  structure  defined  in  section  3.2.1  for  a requirement  provides  the  basis 
for  deriving  basic  categories.  There  must  be  at  least  two  major  indepen- 
dent fields,  one  for  the  THING  (subject)  and  one  for  the  REQUIRED  QUALITY 
(predicate).  Both  of  these  are  too  general  for  the  present  purpose;  their 
major  constituents,  which  may  be  fields  or  facets,  are  the  real  interest. 

Figure  4.2  summarizes  the  basic  categories  proposed  for  classifying  re- 
quirements. The  lower  portion  of  the  figure  consists  of  categories  that  are 
useful  in  particular  situations;  thus  they  are. termed  facets. 

The  figure  is  not  a logical  classification  itself,  and  there  may  well  be 
other  usable  facets  not  included.  A brief  discussion  of  each  category  with 
selected  examples  follows. 

Categories  of  THINGS.  Three  principal  categories  of  THINGS  are  shown  in 
figure  4.2.  They  are:  Physical  Entities,  Human  Entities,  and  Processes. 
(By  definition.  Human  Entities  are  distinct  from  all  other  Physical  Enti- 
ties.) Some  potential  for  ambiguity  exists  between  Human  Entity  and  Pro- 
cess for  some  provisions  and  between  Physical  Entity  and  Process  for  other 
provisions.  These  ambiguities  are  usually  resolvable  by  considering  the 
most  relevant  REQUIRED  QUALITY. 

A most  important  factor  in  the  classification  of  THINGS  is  the  whole -to - 
part  relationship,  shown  as  a "multi-purpose"  facet  in  figure  4.2.  A 
common  characteristic  of  Physical  Entity  classification  is  the  large  number 
of  levels  that  are  typically  related  in  the  fashion  of  "system-subsystem- 
component-constituent . " Similarly,  Processes  can  be  divided  into  stages. 
Great  detail  in  the  whole- to-part  naming  of  Physical  Entities  is  common  in 
prescriptive  standards;  it  is  somewhat  antithetical  to  the  concept  of  a 
performance  standard.  Where  innovation  is  desired,  too  much  whole- to-part 
naming  can  restrict  freedom.  Where  easy  judgment  of  compliance  is  desired, 
a classification  strongly  tied  to  the  most  common  implementations  is  desi- 
rable. As  the  facets  of  figure  4.2  are  reviewed,  the  whole- to-part  rela- 
tionship should  be  kept  in  mind. 

There  is  considerable  richness  in  the  way  the  Physical  Entities  are  named 
and  classified.  Following  are  examples  to  help  define  the  facets  in  figure 
4.2. 

« Function:  the  division  of  stairs  into  required  exits  and  supple- 

mental exits;  the  division  of  a structural  system  into  seismic  re- 
sisting and  non-seismic  resisting  subsystems. 

• Material:  the  division  of  structural  components  into  wood,  steel, 

reinforced  concrete,  masonry,  etc. 

• Dimensions:  the  division  of  buildings  into  one-story  and  multi- 

story. 

• Exposure  (Circumstances) : the  division  of  components  into  those  in 

contact  with  corrosive  fluids,  those  in  contact  with  soil,  etc. 
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Figure  4.2  Basic  categories  for  requirements. 
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• Configuration:  the  division  of  stairs  into  straight,  spiral,  etc. 

• Behavior:  the  division  of  materials  into  brittle  and  ductile. 

• Procedure:  the  division  of  concrete  components  into  those  cast- in- 

place  and  those  precast. 

• Resource:  the  division  of  energy  sources  into  coal,  oil,  nuclear, 

solar,  etc. 

• Time:  the  division  of  buildings  into  existing  and  proposed. 

• Place:  the  division  of  components  by  location  on  the  top  story, 

below  grade,  etc. 

Examples  of  the  facets  for  Human  Entity  are: 

• Activity:  the  division  into  users  of  buildings  and  agents  of  the 

building  process;  the  division  of  users  into  occupants,  maintenance 
crews,  neighbors,  etc. 

• Discipline:  the  division  of  designers  into  architects,  structural 

engineers,  mechanical  engineers,  etc. 

« Time:  the  division  of  licensed  designers  by  the  date  of  registra- 

tion. 

• Place:  the  division  of  licensed  professional  designers  by  state  of 

registration. 

Similar  examples  for  facets  of  Process  are: 

• Agent:  the  division  into  natural  processes,  such  as  corrosion,  and 

human  operations,  such  as  welding. 

® Physical  Entity:  the  division  of  pile  driving  by  types  of  piles, 

for  example:  open  steel  section,  closed  steel  section,  timber,  and 

precast  concrete  piles. 

• Human  Entity:  the  division  of  quality  assurance  activities  into 

those  carried  out  by  the  designer,  the  regulator,  the  contractor, 
etc . 

• Time:  the  division  of  structural  design  into  conceptual  design, 

analysis,  proportioning,  detailing,  etc. 

• Place:  the  division  of  welding  into  shop  welding  and  field  weld- 

ing, or  downhand  and  overhead  welding,  etc. 

Some  useful  facets  may  be  a combination  of  some  of  the  above.  For  example, 
in  standards  for  the  structural  design  of  buildings  a class  of  "stress 
states"  (axial  stress,  flexural  stress,  shear  stress,  etc.)  is  very  useful 
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for  grouping  components.  The  class  can  be  thought  of  as  Function,  Circum- 
stance, or  Behavior,  or  some  combination  of  them. 

Categories  of  REQUIRED  QUALITIES.  The  classification  of  REQUIRED  QUALITIES 
does  not  show  the  richness  of  the  classification  of  THINGS,  but  this  is  not 
an  indication  of  simplicity.  The  first  problem  with  the  categories  shown 
for  REQUIRED  QUALITY  in  figure  4.2  is  that  the  principal  category.  Perfor- 
mance Attribute,  is  not  explicitly  stated  in  some  standards,  particularly 
in  prescriptive  ones.  Another  factor  that  'contributes  to  the  relative 
difficulty  of  developing  a classification  of  REQUIRED  QUALITIES  is  that  the 
whole- to-part  relation  is  rarely  applicable,  making  the  logical  structure 
entirely  dependent  on  the  characteristics  of  the  REQUIRED  QUALITIES. 

In  spite  of  the  problems,  the  classification  of  REQUIRED  QUALITIES  is 
worthwhile  for  two  reasons.  It  is  necessary  to  allow  full  and  relevant 
classification  of  requirements,  without  which  the  access  function  of  the 
organizational  system  would  be  severely  hampered.  It  also  allows  a com- 
pletely independent  arrangement  of  a standard  that  concentrates  on  the 
objective  rather  than  the  subject,  which  is  quite  desirable  for  some  indi- 
viduals and  some  uses.  Thus  the  categories  of  figure  4.2  are  presented 
with  the  knowledge  that  difficulties  may  be  encountered  in  the  classifica- 
tion of  REQUIRED  QUALITIES. 

A useful  subdivision  of  the  performance  hierarchy  is  through  the  use  of 
Limit  States  as  classifiers  of  performance  criteria.  In  the  context  of 
structural  engineering,  a Limit  State  has  been  defined  as  an  event  that  may 
cause  the  loss  of  a performance  attribute  either  by  its  occurrence  or  by 
its  amplitude.  Examples  of  limit  states  and  their  related  performance 
attributes  are  "collapse  of  a building"  (safety) , "vibration  of  a floor" 
(comfort) , and  "cracking  of  a water  tank"  (function) . 

Measure  is  shown  in  figure  4.2  as  a reminder  that  not  all  requirements  can 
be  classified  through  the  performance  hierarchy,  and  that  even  for  those 
that  can  there  exists  a more  basic  facet  for  the  REQUIRED  QUALITY.  In  this 
sense.  Measure  is  all-encompassing  from  the  most  fundamental  qualities, 
such  as  existence,  through  the  more  remote  or  accidental  qualities  like 
"Circumstances . " 

4.1.2  Proper  Usage 

Many  of  the  suggestions  for  proper  usage  have  been  introduced  in  narrative 
form  in  section  4.1.1,  and  will  be  summarized  here  essentially  in  the  order 
in  which  a classification  system  is  developed. 

Basic  Categories.  The  first  and  most  critical  step  in  developing  a classi- 
fication system  is  to  define  the  basic  categories  or  fields  describing  the 
scope  of  a standard.  Figure  4.2  may  be  used  as  a guide,  but  modifications 
or  extensions  of  that  model  may  be  in  order  for  a specific  standard. 

Things  and  Required  Qualities.  In  the  analysis  of  an  existing  standard,  it 
is  usually  easier  first  to  construct  the  classification  system  for  the 
THINGS  covered,  and  then  concentrate  on  their  REQUIRED  QUALITIES.  By 


87 


contrast,  in  synthesizing  a new  standard,  it  is  advisable  first  to  identify 
the  REQUIRED  QUALITIES  sought,  and  only  then  enumerate  the  THINGS  which  are 
to  possess  those  qualities. 

Fields  and  Facets.  The  distinction  between  fields  covering  large  heteroge- 
neous areas  of  subject  matter  and  facets  covering  specific,  homogeneous 
sub -areas  is  often  problematical.  An  evolutionary  approach  is  to  start 
with  many  facets  in  a field  and  then  examine  them  to  see  whether  they  could 
be  logically  combined  into  fewer,  larger  facets. 

Logical  Structure  of  Facets.  Care  must  be  exercised  that  the  classifiers 
within  a facet  satisfy  the  three  rules  of  logical  structure  given  in  sec- 
tion 4.1.1. 

Classing  Provisions.  The  true  test  of  the  classification  system  lies  in 
the  actual  classing  of  provisions,  i.e.,  the  assignment  of  ARGUMENTS  to 
DATUMs . The  ease  with  which  the  five  principles  given  in  section  4,1.1  can 
be  followed  quickly  will  determine  the  usefulness  and  appropriateness  of 
the  classification  system. 

Interaction  with  data  items.  Of  the  five  principles  given  in  section 
4.1.1,  the  most  troublesome  in  practice  is  the  second,  namely,  that  no 
provision  may  be  classed  by  more  than  one  classifier  from  any  facet. 
Potential  violation  of  this  principle  may  mean  that  the  classification  is 
too  detailed,  e.g.,  the  classification  distinguishes  between  "walls"  and 
"diaphragms"  whereas  the  provisions  deal  with  walls  and  diaphragms.  How- 
ever, violation  may  also  occur  because  the  provisions  themselves  are  too 
inclusive,  i.e.,  they  are  multiple  or  cumulative  requirements,  as  defined 
in  section  3.2.1.  In  such  cases,  proper  classification  requires  that  the 
data  items  be  redefined  (see  section  3.2.2). 

4.1.3  Representation 

Each  classifier  is  represented  in  the  SASE  program  by  a classifier  entity. 
The  attributes  describing  a classifier  are  discussed  below. 

REFERENCE  NUMBER  The  reference  number  is  a numeric  key  for  identifying  the 
classifier.  The  reference  number  must  be  unique  within  a version.  A 
convenient  identification  scheme  is  to  use  a five-digit  reference  number, 
the  first  two  digits  referring  to  the  facet  and  the  last  three  digits 
sequentially  assigned  within  the  facet  in  increments  of  ten,  thereby  pro- 
viding space  for  new  classifiers  to  be  inserted  later. 

NAME  Any  short,  mnemonically  meaningful  alphabetic  designation  may  be 
given  to  the  classifier. 

TITLE  Any  descriptive  title,  entered  as  a text  string,  may  be  given  to  the 
classifier;  its  most  common  use  is  in  the  preparation  of  organizations, 
outlines,  and  indexes. 
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TYPE  This  attribute  defines  the  way  the  classifier  is  to  be  used  in  orga- 
nizations and  outlines.  Its  possible  values  are: 

• ACTUAL,  meaning  that  the  classifier  will  be  displayed,  or 

• TRANSPARENT,  meaning  that  the  classifier  will  not  be  displayed  in 
the  outline. 

PARENT  A classifier  may  have  a single  parent  or  multiple  foster  parents. 
If  a parent  is  entered,  identified  by  its  classifier  reference  number,  the 
classifier  belongs  to  the  same  facet  as  its  parent,  and  is  a direct  subdi- 
vision of  the  parent  classifier. 

FOSTER  The  reference  numbers  of  foster  parents  are  entered  only  for  clas- 
sifiers that  are  roots  of  facets.  These  classifiers  will  be  introduced  in 
the  organization  as  if  the  referenced  foster  parent (s)  were  true  parent (s) . 
The  introduction  of  a classifier  having  more  than  one  FOSTER  parent  may  be 
made  conditional  on  a specified  CONTEXT  with  respect  to  classifiers  PRESENT 
or  ABSENT  in  the  hierarchy  above  the  classifier. 

COMMENT  Any  descriptive  information  or  comment,  entered  as  a text  string, 
may  be  attached  to  the  classifier. 

4 . 2 Hierarchy 

4.2.1  Definition 

A hierarchy  is  a tree  of  classifiers.  The  tree  of  a facet  is  formed  by 
assigning  one  classifier  to  each  node  and  forming  a branch  from  each  node 
to  its  parent.  The  tree  of  a field  is  formed  as  follows: 

• the  tree  of  the  root  facet  of  the  field  is  formed; 

• the  trees  of  the  remaining  facets  of  the  field  are  attached  by 

branchs  to  the  foster  parents  of  the  root  nodes  of  the  facets; 

• if  a facet  has  more  than  one  foster  parent,  copies  of  the  tree  of 

the  facet  are  attached  by  branchs  to  each  of  its  foster  parents 
satisfying  the  specified  context. 

The  assembly  of  the  hierarchy  tree  is  readily  done  by  SASE.  The  resulting 
tree  can  be  examined  for  the  desired  properties  of  the  classification 
scheme.  As  an  illustration  of  the  use  of  hierarchies  to  examine  a classifi- 
cation scheme,  figure  4.3  presents  the  Physical  Entity  field  for  a classi- 
fication [9]  for  seismic  provisions  for  buildings.  The  field  has  21  facets. 
A recent  reorganization  [10]  of  the  same  classification  produced  the  Physi- 
cal Entity  field  shown  in  figure  4.4.  The  field  now  has  eight  facets,  them- 
selves arranged  roughly  in  a system- component  hierarchical  order. 
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*Building 

Whole  Building 
Part  of  Building 
^Seismic  Performance 
Category  A 
Category  B 
Category  C 
Category  D 

^Seismic  Hazard  Exposure 
Group  III 

Groups  I and  II  (Not  Used) 
■^Existence  of  Building 
Proposed  (New) 

Existing 

^Material  Nature  of  Bldg  Part 
Material  Generic 
Material  Specific 
*Scale  of  Building  Part 
System 
Component 
Material 

^Function  of  Building  Part 
Structural 

Seismic  Resisting 
Non-Seismic  Resisting 
Foundation 
Non- Structural 
Architectural 
Mechanical/Electrical 
■^Structural  Components 
Connection 
Member  (Not  Used) 

(continued) 


Figure  4.3  Physical  Entity  field  from  a classification  [11] 
for  seismic  provisions  for  buildings  showing  21  facets 
(*  denotes  the  root  of  a facet) . 
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^Materials  of  Construction 
Wood 
Steel 

Reinforced  Concrete 
Masonry 

*Type  of  Seismic  Resisting  Component 
Frame 

Moment  Frame  (Unbraced) 

Ordinary  Moment  Frame 
Special  Moment  Frame 
Braced  Frame 
Shear  Panel 
Shear  Wall 
Diaphragm 
*Frame  Components 
Beam 
Column 
Joint 

*Part  of  Shear  Panel 
Boundary  Member 
Web  (not  used) 

*Part  of  Foundation 
Soil 

Foundation  Structure 
Pile 

Non-Pile  (not  used) 

•*Non- Structural  Components 
Equipment 
Anchorage 

■*Wood  Design  Method 
Conventional 
Engineered 

(continued) 


Figure  4.3  Physical  Entity  field  from  a classification 
for  seismic  provisions  for  buildings  (continued) . 
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*Part  of  Wood  Shear  Panel 
Framing  (Wood) 

Sheathing 

Plywood 

Diagonal  Board 
Other  Sheathing  Material 
■^Reinforced  Concrete  constituents 
Concrete 

Reinforcement  (Concrete) 
Lateral  Reinforcement 
Longitudinal  Reinforcement 
■^Concrete  Pile  Construction 
Cast- in-Place 
Cased 
Uncased 
Precast 

Prestressed 

Non-prestressed  (Not  Used) 
•’'^Masonry  Constituents 

Masonry  Unit,  Mortor,  Grout 
Reinforcement  (Masonry) 
*Masonry  Construction 
Unreinforced 
Stacked  Bond 
Hollow  Unit  Masonry 
*Type  of  Member  Stress 
Axial  Stress 
Flexural  Stress 
Shear  Stress 
Torsion  Stress 


figure  4.3  Physical  Entity  field  from  a classification 
for  seismic  provisions  for  buildings  (concluded) . 


92 


■^Building  Type 
Proposed  (New) 

Existing 

■^Building  Function 

Seismic  Performance  Category 
Category  A 
Category  B 
Categories  C and  D 
Category  C 
Category  D 

Seismic  Hazard  Group 
Group  1 
Group  2 
Group  3 
■^System  Type 
Structural 
Non- S true tural 
Architectural 
Mechanical/Electrical 
Foundation 
^System  Function 

Seismic  Resisting 
Frame 

Moment  Frame  (Unbraced) 
Braced  Frame 
Wall 

Shear  Wall 
Bearing  Wall 
Screen  Wall 
Diaphragm 
Horizontal  Truss 
Non-Seismic  Resisting 
^Material 
Soil 
Wood 

Plywood 

Steel 

Concrete 

Unreinforced  Concrete 
Reinforced  Concrete 
Precast  Concrete 
Cast- in-Place  Concrete 
(continued) 


Figure  4.4  Physical  Entity  field  from  an  alternative 
classification  [12]  for  seismic  provisions  for  buildings 
showing  eight  facets  (*  denotes  the  root  of  a facet) . 
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■^Material  (continued) 

Masonry 

Masonry  Units,  Mortar,  Grout 
Unreinforced  Masonry 
Reinforced  Masonry 
Stacked  Bond  Masonry 
Hollow  Unit  Masonry 
Undifferentiated  Material 
■^Element  Type 
Beam 
Column 
Beam-Column 
Boundary  Member 
Pile 

Uncased  Pile 
Cased  Pile 
Equipment 
Collector  Member 
Tie  Member 

Undifferentiated  Element  Type 
*Part  of  Element  or  System 
Reinforcement 

Lateral  Reinforcement 
Longitudinal  Reinforcement 
Reinforcement  Splice 
Reinforcement  Anchorage 
Joint 

Member  Anchorage 
Opening 

Sheathing  and  Diagonal  Board 
Undifferentiated  Part 
^Element  Function  (stress) 

Axial  Stress 
Flexural  Stress 
Shear  Stress 
Torsional  Stress 

Undifferentiated  Element  Function 


Figure  4.4  Physical  Entity  field  from  an  alternative 
classification  for  seismic  provisions  (concluded) . 
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4.2.2  Proper  Usage 

Proceed  from  small  to  big.  It  is  best  to  generate  and  examine  smaller 
hierarchies  corresponding  to  individual  facets  before  combining  classifiers 
into  larger  fields. 

Generate  early  and  often.  Hierarchies  should  be  generated  and  examined  as 
soon  as  a few  classifiers  have  been  identified,  and  regenerated  whenever  a 
significant  number  of  classifiers  is  added  or  their  relations  modified. 

Correct  for  loops.  If  the  analysis  reveals  the  presence  of  loops,  these 
must  be  eliminated  by  redefining  parent  or  foster  parent  relations  among 
classifiers.  Unlike  loops  in  networks  (see  section  3.6),  loops  among  clas- 
sifiers arise  infrequently,  and  are  more  likely  caused  by  data  entry  errors 
than  by  logical  flaws  in  the  definition  of  classifier  hierarchies. 

4.2.3  Representation 

In  SASE,  a hierarchy  is  generated  by  the  GENERATE  HIERARCHY  command.  Since 
all  classifiers  are  identified  with  a VERSION  of  a standard,  the  hierarchy 
does  not  have  an  explicit  reference  number.  If  the  FACET  qualifier  is  used, 
separate  facet  hierarchies  will  be  generated  using  the  PARENT  attributes 
only,  starting  from  the  root  nodes  of  each  facet  (root  nodes  of  facets  have 
no  PARENT) . If  the  ALL  qualifier  is  used,  the  facets  will  be  combined  into 
FIELDS,  by  connecting  root  nodes  of  facets  through  their  FOSTER  parent (s) . 
The  hierarchy  will  start  from  the  root  node(s)  of  field(s)  (root  nodes  of 
fields  have  neither  PARENT  nor  FOSTER  parent) . The  inclusion  in  a particu- 
lar field  of  a facet  root  node  having  more  than  one  FOSTER  parent  is  condi- 
tional on  the  CONTEXT  specified  for  each  FOSTER  parent  (see  section  4.1.3). 

SASE  produces  error  messages  if: 

• a loop  is  detected  (i.e.,  the  hierarchy  is  not  a strict  tree),  in 
which  case  a list  of  the  nodes  (classifier  reference  numbers)  that 
form  the  loop  is  printed; 

• a GENERATE  HIERARCHY  ALL  is  requested,  but  one  or  more  facet  root 
nodes  are  not  linked  up  through  FOSTER  parents. 

In  either  case,  the  user  must  MODIFY  the  PARENT  or  FOSTER  parent  of  one  or 
more  classifiers  before  the  hierarchy  can  be  generated. 

The  DISPLAY  HIERARCHY  command  provides  a number  of  options  for  displaying  a 
hierarchy: 

• the  display  can  show  ALL  nodes  or  only  ROOTs  or  FIELDS  or  FACETs , 

• the  display  can  include  the  hierarchy  of  the  entire  VERSION  or  only 
a selected  FIELD  or  FACET,  and 

• the  display  can  be  in  STRUCTURE  (indented)  or  LIST  (tabular)  form. 
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4 . 3 Scopelis t 


4.3.1  Definition 

The  scopelist  is  the  basic  cross-reference  between  classifiers  and  data 
items.  The  scopelist  is  generated  by  appending  to  each  classifier  the  list 
of  all  data  items  having  that  classifier  as  one  of  its  arguments.  Thus, 
each  datum  will  appear  under  each  of  the  classifiers  in  its  argument  list. 
A scopelist  for  the  fire  escape  example  was  shown  in  table  2.10.  An  example 
in  SASE  format  is  given  in  Appendix  A. 

4.3.2  Proper  Usage 

Proceed  from  small  to  big.  It  is  best  to  generate  and  examine  smaller 
scopelists  before  generating  larger  ones.  As  soon  as  the  hierarchy  of  a 
facet  appears  satisfactory,  it  is  advisable  to  generate  a scopelist  for 
that  facet.  Examination  of  the  data  items  under  each  classifier  will  help 
in  "calibrating"  the  classification  scheme,  namely,  in  deciding  whether  the 
classifiers  appropriately  identify  and  group  related  provisions.  It  may  be 
advisable  to  perform  this  analysis  on  data  items  from  individual  chapters 
before  performing  it  on  the  entire  version.  Conversely,  particularly  in 
synthesis,  if  the  scopelist  of  some  classifier(s)  contains  isolated  data 
items  from  several  chapters,  regrouping  those  data  items  into  more  closely 
related  chapters  and  redefining  the  classification  scheme  may  both  be 
appropriate . 

Balance . The  scopelist  should  be  carefully  reviewed  for  classifiers  with 
an  excessively  large  number  of  data  items  (the  COUNT  option  is  useful  as  a 
preliminary  screening  tool) . Such  large  "clusters"  warrant  a review  of 
both  the  classification  scheme  (to  see  whether  one  or  more  classifiers 
should  be  further  subdivided)  and  the  data  items  (to  see  whether  require- 
ments of  the  multiple  or  cumulative  type  should  be  subdivided) . 

4.3.3  Representation 

In  SASE,  a scopelist  is  generated  by  the  GENERATE  SCOPELIST  command.  There 
can  be  only  one  SCOPELIST  for  each  VERSION  of  a standard.  Therefore,  the 
scopelist  does  not  have  an  explicit  reference  number.  The  user  must  spe- 
cify the  CHAPTERS  to  be  included  in  the  scopelist.  A hierarchy  must  have 
been  previously  generated. 

The  DISPLAY  SCOPELIST  command  provides  a number  of  options  for  displaying  a 
scopelist : 

• all  the  options  on  choice  and  formats  of  classifiers  discussed  in 
section  4.2.3; 

• the  choice  of  all  data  items  or  only  REQUIREMENTS  or  DETERMINATIONS 
(COUNT  gives  just  the  number  of  data  items  rather  than  a listing) ; 

® the  choice  of  all  classifiers  or  only  those  used  for  OUTLINing  or 
INDEXing. 


96 


4 . 4 Index 


4.4.1  Definition 

An  index  is  a list  of  classifiers  with  a list  of  references  to  provisions 
associated  with  each  classifier  that  provides  access  to  the  provisions. 
The  simplest  form  is  an  alphabetical  arrangement  of  the  classifiers  in  a 
single  level,  with  a cluster  of  references  to  the  provisions  associated 
with  each  classifier  given  below  (hereafter  called  a "simple  index"). 
Figure  4.5  is  an  example  of  such  an  index;  it  is  a portion  of  the  index 
produced  for  [18].  Each  reference  in  a cluster  consists  of  three  parts: 
the  datum  number,  the  descriptive  title  of  the  datum,  and  the  section  or 
chapter  number  of  the  original  text  containing  the  provision.  The  datum 
number  alone  might  suffice  for  access  in  some  instances,  but  the  descrip- 
tive title  is  particularly  helpful  in  a simple  index.  It  would  be  possible 
to  include  the  page  number.  Note  that  the  most  common  index  for  a book  is 
a single  level  list  of  headings  with  a cluster  of  page  numbers  for  each 
heading . 

A characteristic  defect  of  simple  indexes  is  that  many  headings  reference 
clusters  containing  too  many  provisions  for  efficient  use.  An  index  with 
multiple  levels  of  headings,  such  as  in  figure  4.6a,  aids  the  user  by 
subdividing  the  clusters  of  references  to  provisions  into  more  intelligible 
groups . 

Indexing  principles  can  be  formulated  for  indexes  with  multiple  levels  of 
headings  and  for  indexes  with  several  classifiers  for  each  heading  (see 
figure  4.6  for  examples  of  both).  The  former  type  is  quite  useful  for 
large  indexes.  The  latter  type  introduces  more  power  and  possibly  more 
relevance,  but  also  causes  additional  problems  of  length.  It  does  not  seem 
worth  the  added  cost  when  the  provision  reference  in  the  index  contains  the 
datum  description,  because  the  description  and  a heading  containing  most  or 
all  of  the  arguments  of  the  provision  are  frequently  very  similar. 

It  is  useful  to  include  both  requirements  and  determinations  in  the  index. 
Even  though  all  terminal,  or  highest  level,  data  items  correspond  to  re- 
quirements, use  of  the  standard  frequently  requires  access  to  non- terminal 
provisions  for  many  purposes.  This  is  particularly  true  for  determinations 
that  evaluate  important  characteristic  quantities.  The  outline  system 
primarily,  but  not  wholly,  provides  access  to  the  requirements,  and  the 
information  network  system  primarily  provides  access  to  determinations 
through  the  ordering  of  the  global  ingredience  of  requirements.  The  index 
is  essentially  a backup  access  system  and  must  provide  access  for  both 
types  of  provisions. 

As  described  in  section  4.1.1,  the  logical  principles  for  classing  a provi- 
sion may  be  violated  for  the  purpose  of  Indexing.  Generally  speaking,  the 
arguments  of  a provision  for  outlining  will  be  fewer  in  number  than  those 
for  indexing.  A common  example  would  be  a requirement  with  compound  THINGS 
or  REQUIRED  QUALITIES.  Such  a provision  must  be  related  to  a general  clas- 
sifier for  unique  placement  in  an  outline,  but  for  reliable  access  through 
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ALPHABETICAL  INDEX 


REFERENCE  LOCATION 


ACCESS/EGRESS;  BLOCKED 

1472  GROUP  III  ACCESS  REQUIREMENT 

ALTERATION 

1380  ALTERATION  AND  REPAIR  REQUIREMENT 
ANALYSIS 

3105  STRUCTURAL  ANALYSIS  REQUIREMENT 

3381  CATEGORY  C AND  D INTERACTION  REQUIREMENT 

4001  EQUIVALENT  LATERAL  FORCE  ANALYSIS  REQUIREMENT 

5001  MODAL  ANALYSIS  REQUIREMENT 

5210  MODELING  REQUIREMENT 

5310  MODES  REQUIREMENT 

5410  PERIOD  AND  MODE  SHAPE  ANALYSIS  REQUIREMENT 
6001  SOIL  STRUCTURE  INTERACTION  ANALYSIS  REQUIREMENT 

ANALYTICAL  EVALUATION 

13226  ANALYTICAL  EVALUATION  PROCEDURES  REQUIREMENT 

13228  ANALYSIS  METHOD  REQUIREMENT 

13230  DETAILS  OF  ANALYTICAL  EVALUATION  REPORT  REQ 

13246  RESULTS  OF  ANALYTICAL  EVALUATION 

13248  GOVERNING  EARTHQUAKE  CAPACITY  RATIO 

13262  ALLOWABLE  EARTHQUAKE  CAPACITY  RATIO 

ANCHORAGE 

8165  ARCH/MECH/ELEC  ATTACHMENT  REQUIREMENT 

8240  EXTERIOR  WALL  PANEL  ATTACHMENT  REQUIREMENT 

8315  AMPLIFICATION  FACTOR  FOR  ATTACHMENT  OF  M/E  COMP 

8321  TYPE  OF  RESILIENT  MOUNTING  SYSTEM 

8345  MECH/ELEC  ATTACHMENT  DESIGN  REQUIREMENT 

8369  M/E  ATTACHMENT  CERTIFICATION  (TESTING)  REQUIRED 

ARCHITECTURAL 

8100  ARCH/MECH/ELEC  PROVISIONS  APPLICABLE 

8105  ARCH/MECH/ELEC  PERFORMANCE  LEVEL 

8106  PERFORMANCE  LEVEL  FROM  TABLES -B 
8190  PERFORMANCE  CHARACTERISTIC  FACTOR 
8200  ARCHITECTURAL  DESIGN  REQUIREMENT 

8215  SEISMIC  FORCE  FOR  ARCHITECTURAL  COMPONENTS 
8220  SEISMIC  COEFFICIENT  FOR  ARCHITECTURAL  COMP 
8240  EXTERIOR  WALL  PANEL  ATTACHMENT  REQUIREMENT 


Figure  4.5  Example  of  a simple  index 


1.4.2(E) 


1.3.2 


3.1 

3.3.4(B) 
CHAPTER  4 
CHAPTER  5 

5.2 

5.3 

5.4 

CHAPTER  6 


13.2.2 

13.2.2 

13.2.2 

13.2.2 

13.2.2 

13.2.2 


8.1.2 

8.2.3 
8.3.2(A) 
8.2.3,  2.1 

8.3.3 

8.3.4 


8.1 

8.1,  8.1.3 
TBL  8-B 

8.1.3,  TBL  8 -A 

8. 2. 1-5 

8.2.3 

8.2.3 

8.2.3 
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CATEGORY  A 

3620  CATEGORY  A DESIGN  AND  DETAILING  REQUIREMENT 
9300  CATEGORY  A WOOD  REQUIREMENT 
11300  CATEGORY  A CONCRETE  REQUIREMENT 
11310  CATEGORY  A CONCRETE  FRAMING  REQUIREMENT 
11340  CATEGORY  A CONCRETE  ANCHOR  BOLT  REQUIREMENT 
CATEGORY  B 
BEAM 

11602  ORDINARY  CONCRETE  FLEXURAL  MEMBER  REQUIREMENT 
11604  ORDINARY  CONCRETE  FLEXURAL  MEMBER  REINFORCEMENT  REQUIREMENT 
11618  ORDINARY  CONCRETE  FLEXURAL  MEMBER  MOMENT  RESISTANCE  REQ 
11628  ORDINARY  CONCRETE  FLEXURAL  MEMBER  REINFORCEMENT  ANCHORAGE  REQ 
11640  ORDINARY  CONCRETE  FLEXURAL  MEMBER  WEB  REINFORCEMENT  REQ 
CASED 

7476  CATEGORY  B CASED  CONCRETE  PILE  REQUIREMENT 
COLUMN 

11662  ORDINARY  CONCRETE  BEAM  COLUMN  LATERAL  REINFORCEMENT  REQ 
COMPONENT 
CASED 

7476  CATEGORY  B CASED  CONCRETE  PILE  REQUIREMENT 
CONCRETE 

7452  CATEGORY  B UNCASED  CONCRETE  PILE  REQUIREMENT 
7476  CATEGORY  B CASED  CONCRETE  PILE  REQUIREMENT 
7490  CATEGORY  B CONCRETE  FILLED  STEEL  PIPE  PILE  REQUIREMENT 
7492  CATEGORY  B PRECAST  CONCRETE  PILE  REQUIREMENT 
7494  CATEGORY  B PRESTRESSED  CONCRETE  PILE  REQUIREMENT 
DETAILED  DESIGN 

3630  CATEGORY  B DESIGN  AND  DETAILING  REQUIREMENT 
3640  CATEGORY  B OPENINGS  REQUIREMENT 

a)  Multiple  level  headings 

CATEGORY  B CONCRETE  ORDINARY  MOMENT  FRAME 

11600  CATEGORY  B CONCRETE  ORDINARY  MOMENT  FRAME  REQUIREMENT 
11602  ORDINARY  CONCRETE  FLEXURAL  MEMBER  REQUIREMENT 
11604  ORDINARY  CONCRETE  FLEXURAL  MEMBER  REINFORCEMENT  REQUIREMENT 
11618  ORDINARY  CONCRETE  FLEXURAL  MEMBER  MOMENT  RESISTANCE  REQ 
11628  ORDINARY  CONCRETE  FLEXURAL  MEMB.  REINFORCEMENT  ANCHORAGE  REQ 
11640  ORDINARY  CONCRETE  FLEXURAL  MEMBER  WEB  REINFORCEMENT  REQ 
CATEGORY  B CONCRETE  PILE  REINFORCEMENT 

7452  CATEGORY  B UNCASED  CONCRETE  PILE  REQUIREMENT 

7476  CATEGORY  B CASED  CONCRETE  PILE  REQUIREMENT 

7490  CATEGORY  B CONCRETE  FILLED  STEEL  PIPE  PILE  REQUIREMENT 

7492  CATEGORY  B PRECAST  CONCRETE  PILE  REQUIREMENT 

7494  CATEGORY  B PRESTRESSED  CONCRETE  PILE  REQUIREMENT 

b)  Multiple  classifier  headings 


Figure  4.6  Examples  of  advanced  indexes 


99 


an  index  it  would  be  better  if  the  provision  were  related  to  specific 
classifiers  for  each  of  the  compounded  THINGS  or  REQUIRED  QUALITIES.  Ano- 
ther common  example  is  the  addition  of  more  general  classifiers  for  index- 
ing when  the  arguments  are  of  a very  narrow  scope. 

In  some  instances,  classifiers  are  associated  with  provisions  purely  for 
the  purpose  of  arrangement  in  outlining.  For  example,  requirements  for  the 
performance  of  a structure  might  be  classed  according  to  the  stages  of  the 
design  process  in  which  the  requirement  normally  would  be  satisfied.  Such 
classification  is  relevant  in  outlining,  but  possibly  can  be  misleading  in 
indexing,  if  the  same  classifiers  are  used  (1)  to  indicate  the  THING  or 
REQUIRED  QUALITY  of  some  requirements  and  (2)  for  arranging  some  other 
requirements  pertaining  to  other  THINGS  or  REQUIRED  QUALITIES.  The  user  of 
the  index  has  no  sure  way  of  distinguishing  between  these  two  purposes,  and 
he  might  assume  that  the  heading  (classifier)  is  related  to  the  THING  for 
each  associated  provision.  For  the  purpose  of  indexing,  a provision  should 
be  deleted  from  the  scope  list  of  a classifier  when  that  classifier  is 
associated  with  the  provision  only  for  purposes  of  arrangement  in  outlin- 
ing. 

Logical  classing  is  not  necessary  for  indexing  because  the  structure  of  an 
index  depends  primarily  on  the  relation  of  a classifier  and  a provision. 
The  relations  between  classifiers  are  much  less  important.  The  index  does 
not  have  a unique  location  for  each  provision  reference;  it  generally  will 
have  several,  even  if  the  classing  is  strictly  logical.  The  index  benefits 
from  relaxation  of  logical  rigor  when  it  can  make  the  product  more  natural, 
and  when  the  relaxation  can  do  no  harm. 

An  alphabetical  ordering  of  the  headings  in  an  index  is  meaningful  and  well 
accep.ted.  The  other  choice  for  indexing  is  to  order  the  headings  by  their 
positions  in  the  trees  of  classifiers.  The  Alphabetical  order  appears 
preferable  because  it  is  common  to  so  many  indexes  and  because  doing  so 
relieves  one  from  making  decisions  about  the  ordering  of  fields  and  facets 
for  use  as  an  index.  Adopting  the  alphabetical  order  adds  importance  to 
the  ordering  of  words  in  multi-word  headings.  Thus  classifiers  containing 
more  than  one  word  ideally  should  have  the  most  relevant  word  placed  first. 

The  production  of  an  alphabetical  index  of  the  simple  type  on  a computer  is 
quite  elementary,  once  the  classification,  the  provision  references,  and 
the  arguments  for  each  provision  have  been  stored.  Two  preliminary  steps 
are  the  transposition  of  the  argument  lists  to  determine  the  provisions 
associated  with  each  classifier  (i.e.,  generation  of  the  scopelist)  and  the 
alphabetical  sorting  of  the  classifier  names.  The  only  decision-making 
necessary  during  the  generation  of  the  index  is  to  suppress  those  classi- 
fiers associated  with  no  provisions  (common  for  very  general  classifiers) , 
to  delete  those  classifiers  associated  with  too  many  provisions  to  be 
useful,  and  to  delete  provisions  from  the  scope  list  of  a classifier  when 
the  association  is  for  purposes  of  arrangement  only. 
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4.4.2  Proper  Usage 


Generate  sparingly.  Unlike  the  scopelist,  the  index  may  take  considerable 
computer  time  to  generate , and  may  provide  too  much  information  to  analyze 
and  evaluate  thoroughly.  Therefore,  it  is  recommended  that  analyses  and 
modifications  be  based  on  the  scopelist  generated,  and  the  index  be  used 
only  in  the  final  phase  of  formulating  a standard. 

4.4.3  Representation 

In  SASE,  an  index  is  generated  by  the  GENERATE  INDEX  command.  There  can  be 
only  one  index  for  each  VERSION  of  a standard.  Therefore,  the  index  does 
not  have  an  explicit  reference  number.  A SCOPELIST  must  have  been  pre- 
viously generated. 

The  index  may  be  specified  as  SIMPLE,  with  a single  level  of  classifier 
headings,  or  SUBDIVIDED  according  to  classifier  levels,  so  as  to  break  up 
large  clusters  of  provisions.  Certain  classifiers  may  be  DROPped  from  the 
index;  by  specific  classifier  numbers,  by  specific  ROOTs  of  field  or  fa- 
cets, or  those  whose  scopelist  exceeds  a certain  number  or  percentage  of 
the  total. 

The  DISPLAY  INDEX  command  provides  a number  of  options  for  displaying  an 
index,  which  may  include: 

• all  classifiers  or  only  those  of  specific  FIELDS  or  FACETs ; 

• all  data  items  in  the  scopelists  or  only  REQUIREMENTS  or  DETERMINA- 
TIONS : 

• a COUNT  of  the  data  items  in  each  scopelist  rather  than  their  list- 
ing. 

4 . 5 Organization 

The  concepts  of  organization  and  outline  are  closely  related.  The  reader 
should  be  comfortable  with  the  material  in  both  this  section  and  in  section 

4.6  before  creating  extensive  organizations  and  outlines  for  a standard. 

4.5.1  Definition 

An  organization,  or  more  precisely,  its  dual  representation,  an  organiza- 
tional tree,  is  a tree  of  classifiers  formed  by  appending  nuclear  trees 
from  various  facets  and  fields.  An  organization  is  the  list  representation 
of  its  organizational  tree,  with  the  structure  and  classifiers  in  the  tree 
converted  into  hierarchical  headings  in  the  organization.  An  organizational 
tree  differs  from  a hierarchy  (see  section  4.2),  in  that  the  organizational 
tree  is  "built"  one  nuclear  tree  at  a time  (that  is,  one  parent  classifier 
and  its  immediate  descendent  classifiers),  whereas  for  the  hierarchy,  once 
the  root  of  a facet  is  included,  the  entire  tree  of  that  facet  is  included. 
An  organization  differs  from  an  outline  (see  section  4.6)  in  that  the 
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organization  contains  only  the  classifiers  as  headings,  whereas  the  outline 
contains  also  the  provisions  entered  at  the  appropriate  headings. 

In  synthesis,  the  goal  of  the  organization  process  is  to  assist  standards 
writers  in  defining  the  scope  of  a new  standard  by  identifying  those  combi- 
nations of  classifiers  that  correspond  to  potential  provisions.  In  expres- 
sion, the  goal  is  to  assist  users  of  an  existing  standard  in  quickly  and 
reliably  locating  the  relevant  provisions  by  providing  a logical  arrange- 
ment for  them.  An  effective  organization,  one  •.  that  meets  these  goals,  pos- 
sesses five  qualities: 

1.  Relevant:  Each  heading  is  significantly  related  to  its  provi- 

sions; it  concisely  expresses  their  scope. 

2.  Meaningful:  The  reader  perceives  the  heading  as  being  relevant  to 

the  provision. 

3.  Unique:  The  headings  are  distinct  from  one  another  to  allow 

readers  to  access  provisions  unambiguously. 

4.  Complete:  The  total  set  of  headings  covers  the  entire  scope  of 

the  standard  and  nothing  more. 

5.  Graded:  The  headings  show  a regular  gradation  in  scope  through 

the  levels. 

Additional  qualities  are  desirable  for  an  efficient  organization: 

6.  Progressive:  The  headings  at  any  level  are  ordered  in  a pattern 

significant  to  the  reader. 

7.  Intelligible:  The  depth  (the  number  of  levels  in  an  organization) 

and  breadth  (the  number  of  headings  at  one  level)  does  not  exceed 
the  span  of  immediate  memory  of  the  reader. 

8.  Minimal:  The  number  of  headings  is  the  minimum  necessary  for 

meaningful  access. 

9.  Even:  The  organization  divides  the  provisions  so  that  depth  and 

breadth  do  not  vary  greatly  from  one  part  to  another. 

Criteria  for  judging  the  effectiveness  and  efficiency  of  an  organization 
can  be  developed  for  each  of  these  qualities.  Criteria  for  the  first  and 
second  qualities  - -Relevant  and  Meaningful- -can  be  evaluated  completely  only 
when  an  outline  is  developed  from  the  organization;  discussion  of  these 
qualities  carries  into  section  4.6.  Criteria  for  the  other  qualities  can  be 
evaluated  on  the  basis  of  the  ordering  and  grouping  of  the  classifiers 
only.  The  ability  to  generate  and  evaluate  alternative  organizations 
before  introducing  the  provisions  is  a valuable  tool  for  both  the  synthesis 
and  the  expression  of  standards.  An  example  of  an  organization  was  pre- 
sented in  the  fire  escape  example  in  Chapter  2. 
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Use  in  Synthesis.  The  process  of  synthesizing  a new  standard  includes  the 
identification  of  provisions  potentially  to  be  included  in  the  standard. 
This  identification  is  accomplished  in  several  stages.  Iteration  of  the 
stages  is  normal. 

In  the  first  stage,  a "top-down"  classification  is  constructed.  This  must 
include  at  least  one  field  for  THING  and  one  for  REQUIRED  QUALITY.  Top-down 
classification  is  essentially  a way  of  making  decisions  about  scope,  and 
then  retaining  those  decisions  as  the  criteria  for  completeness  and  rele- 
vance in  the  organization  of  a standard.  It  is  practicable  because  the 
classification  of  the  subjects  and  objectives  of  a standard  automatically 
gives  a classification  for  the  THINGs  and  REQUIRED  QUALITIES  for  the  re- 
quirements of  the  standard.  Classification  has  already  been  discussed  in 
detail  in  section  4.1. 

In  the  second  stage,  an  organizational  tree  is  constructed  from  the  classi- 
fication. The  purpose  of  constructing  the  organizational  tree  is  to  produce 
the  combinations  of  THING  and  REQUIRED  QUALITY  classifiers  that  correspond 
to  provisions.  The  ordering  of  provisions  is  not  of  particular  concern  at 
this  stage. 

The  construction  of  the  organizational  tree  is  presented  as  a formal  algo- 
rithm below.  This  classifier-driven  algorithm  has  not  been  implemented  in 
SASE  but  is  presented  here  as  an  aid  to  the  reader  constructing  an  organi- 
zation manually  using  the  available  SASE  tools. 

The  first  step  is  to  explode  the  trees  of  the  classification  into  nuclear 
trees  (recall  that  a nuclear  tree  is  defined  in  section  4.1  as  a classifier 
and  its  direct  children).  Thus,  the  process  of  appending  trees  into  an 
organizational  tree  deals  with  one  set  of  logical  siblings  at  a time.  The 
relations  among  and  within  facets  are  not  forgotten  in  this  step;  each 
nuclear  tree  belongs  to  a certain  facet  and  field,  and  the  context  condi- 
tions for  a facet  apply  to  each  of  the  nuclear  trees  taken  from  it. 

The  second  step  is  to  select  the  root  of  one  of  the  major  THING  or  REQUIRED 
QUALITY  fields  as  the  root  of  the  organizational  tree.  The  process  of 
appending  begins  with  consideration  of  its  first  child,  which  is  the  first 
terminal  node  to  be  examined  in  step  three. 

The  third  step  is  the  heart  of  the  algorithm.  Considering  the  classifiers 
on  the  branch  from  the  root  to  any  particular  terminal  node  as  the  "stack", 
the  stack  and  the  remaining  nuclear  trees  are  examined  to  determine  whether 
it  is  necessary,  appropriate,  or  possible  to  append  an  additional  nuclear 
tree.  Because  the  model  of  a basic  requirement  has  a THING  as  subject  and  a 
REQUIRED  QUALITY  as  predicate,  it  is  necessary  to  append  another  tree  if 
the  stack  does  not  contain  the  root  nuclear  trees  for  the  field  of  THING 
and  the  field  of  REQUIRED  QUALITY.  It  is  often  appropriate  that  the  stack 
contains  more  than  one  classifier  for  either  or  both  of  these  two  catego- 
ries. The  possibility  of  appending  a nuclear  tree  is  governed  by  the 
following  rules ; 


103 


1.  Relevant:  a nuclear  tree  whose  parent  is  the  root  of  a field  may 

be  appended  at  any  location;  a nuclear  tree  whose  parent  is  the 
root  of  a facet  but  not  a field  may  be  appended  when  a class  that 
the  facet  expands  is  present  on  the  branch;  and  a nuclear  tree 
whose  parent  is  neither  may  be  appended  when  a predecessor  is  on 
the  branch. 

2.  Unique:  only  one  nuclear  tree  may  be  appended  to  any  single  node 

of  an  organizational  tree. 

3.  Graded:  a nuclear  tree  may  not  be  appended  where  a descendant  of 

the  tree  is  already  on  the  branch. 

4.  Complete:  all  the  siblings  shall  be  retained  when  appending  the 

nuclear  tree. 

5.  Progressive:  the  order  of  the  siblings  in  the  organizational  tree 

shall  be  the  same  as  in  the  original  classification. 

6.  Minimal:  larger  nuclear  trees  should  be  appended  after  smaller 

nuclear  trees . 


If  the  conditions  are  met,  the  nuclear  tree  is  appended  by  "burying"  the 
parent  at  the  current  terminal  node  and  then  processing  to  its  first  child. 
The  third  step  is  then  repeated.  If  more  than  one  nuclear  tree  are  possi- 
ble candidates,  the  most  appropriate  should  be  selected  from  due  considera- 
tion of  the  consequences  of  the  subsequent  execution  of  step  three.  If  no 
possibility  of  appending  another  tree  exists,  proceed  to  step  four. 

The  fourth  step  is  to  select  the  next  appropriate  action  once  a branch  is 
terminated.  If  the  terminal  classifier  has  a sibling  remaining,  proceed  to 
it  and  execute  step  three  for  the  new  branch.  If  no  sibling  remains, 
examine  the  parent  in  the  organizational  tree  (note  that,  in  general,  this 
would  not  be  the  parent  of  the  nuclear  tree) . If  that  classifier  is  not  a 
root  of  a field,  the  fourth  step  is  repeated.  If  that  classifier  is  a root 
and  if  no  other  fields  remain  that  can  be  used  to  start  a new  tree  (or  a 
new  "trunk"),  then  the  algorithm  is  completed.  If  such  fields  remain,  the 
root  can  be  appended  and  the  algorithm  continued  from  step  two. 

If  the  resulting  tree  contains  each  field  in  the  classification  such  that 
each  terminal  classifier  from  the  root  nuclear  tree  of  each  THING  field  is 
combined  with  each  terminal  classifier  from  the  root  nuclear  tree  of  each 
REQUIRED  QUALITY  field,  then  the  tree  covers  the  scope  of  the  classifi- 
cation. Note  that  different  THING  fields  need  not  be  combined  and  that 
descriptive  REQUIRED  QUALITY  facets  do  not  control  any  check  for  complete- 
ness. The  order  in  which  classifiers  occur  on  a branch  is  not  a factor  in 
this  algorithm  (except  for  hierarchical  considerations)  although  it  is  a 
consideration  in  some  techniques  for  arrangements. 

Several  of  the  rules  for  appending  nuclear  trees  used  in  this  algorithm 
deserve  further  discussion.  The  first  rule,  Relevant,  reflects  the  follow- 
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ing  considerations.  Fields  are  independent  classifications;  there  is  no 
situation  where  appending  the  root  nuclear  tree  of  a field  would  be  irrele- 
vant, provided  the  logical  rules  are  not  violated.  Facets  that  are  not  the 
root  of  a field  are  not  independent;  they  are  a subdivision  of  some  other 
class  or  classes  in  their  field.  Thus  it  would  be  irrelevant  to  append  the 
root  of  a facet  unless  such  a class  is  already  in  the  organizational  tree. 
For  example,  "Cast- in-place"  and  "Precast"  are  the  siblings  in  a nuclear 
tree  that  serves  to  modify  the  class  "Concrete".  Appending  that  nuclear 
tree  to  "Steel"  would  be  irrelevant. 

For  the  nuclear  tree  that  is  not  the  root  of  a facet  (the  third  type  men- 
tioned) , the  simplest  rule  for  relevant  appending  would  be  that  the  parent 
of  the  nuclear  tree  must  be  present  on  the  branch  (not  necessarily  at  the 
terminus).  This  has  great  intuitive  appeal,  but  in  practice  it  seems  to  be 
too  rigid.  Relevance  depends  a great  deal  on  the  specific  context  of  the 
situation,  but  a few  generalizations  are  in  order.  First,  relevance  is 
much  less  likely  if  an  extended  sibling  is  present  on  the  branch.  (An 
extended  sibling  is  a classifier  from  the  same  facet  that  is  neither  a 
predecessor  nor  a descendant  [See  section  4.6].)  Second,  relevance  is 
possible  even  through  the  parent  is  not  present,  as  long  as  some  predeces- 
sor is  present.  Strict  application  of  a rule  requiring  the  parent  to  be 
present  ignores  this  second  obseirvation,  introducing  unwanted  depth  in 
organizational  trees  and  reducing  desirable  flexibility. 

A system  for  recording  relations  among  facets  is  incorporated  in  SASE.  It 
is  designed  to  meet  the  need  to  determine  the  eligibility  of  a facet.  In 
this  system,  each  facet  (except  the  root  of  a field)  is  attached  to  one  or 
more  "foster  parents,"  which  are  simply  other  classifiers  in  the  field. 
The  foster  parents  need  not  be  terminal  classifiers  on  a facet.  In  addi- 
tion, each  link  between  a facet  and  a foster  parent  may  be  made  conditional 
be  specifying  and  recording  a "context"  (see  section  4.1).  Contexts  take 
the  form  of  conditions  that  given  classifiers  must  be  present  or  absent  (in 
the  organizational  tree)  for  the  relation  between  the  foster  parent  and  the 
facet  to  be  relevant.  For  example,  the  facet  "Concrete  Pile  Construction" 
may  be  appended  when  its  foster  parent  "Pile"  is  on  the  branch  of  the 
organizational  tree  only  if  the  classifier  "Concrete"  is  also  on  the 
branch.  (Use  of  such  a system  for  checking  the  relevance  between  a classi- 
fier and  argument  for  the  purpose  of  provision  entry  requires  a more  thor- 
ough specification  of  the  permissible  links  for  successful  use.) 

The  second  rule.  Unique,  prevents  the  creation  of  "step  siblings"  in  the 
organization.  In  the  following  example  derived  from  [18],  "Pile"  and 
"Strength"  have  been  made  step  siblings: 

Foundation 

Soil 

Foundation  Structure 
Strength 

Interrelationship 

Pile 

Existence 

Details 
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Because  of  this  forced  relationship,  the  question  arises  whether  piles  will 
be  included  in  strength  (and  interrelationship)  requirements  for  the  foun- 
dation structure.  Violation  of  this  rule  has  been  quite  common  in  past 
models  for  organization. 

Finally,  it  should  be  apparent  that  this  classifier-driven  algorithm  can 
generate  an  extremely  large  organizational  tree  because  of  the  assumed 
independence  of  the  various  fields  and  because  of  the  requirement  for 
completeness.  The  "top  down"  development  of  a classification  advocated  at 
the  beginning  of  this  section  helps  minimize  the  size  of  the  resulting 
organizational  tree. 

Use  in  Expression.  The  capability  to  generate  alternative  organizations  for 
a set  of  existing  provisions  is  a key  aspect  of  the  SASE  methodology.  The 
needs  for  a method  with  enough  rigor  to  preserve  and  promote  the  relevance 
and  logic  incorporated  in  the  classification  system  and  yet  with  enough 
flexibility  to  provide  several  arrangements  might  seem  contradictory.  None- 
the-less,  such  a capability  is  central  to  SASE. 

Compared  to  generating  an  organizational  tree  in  synthesis,  generating  an 
organizational  tree  in  expression  does  not  demand  the  presence  of  at  least 
one  field  for  THING  and  one  for  REQUIRED  QUALITY,  nor  does  it  require 
strict  enforcement  of  the  completeness  rule  for  appending  nuclear  trees, 
because  the  resulting  organization  will  serve  only  to  order  the  existing 
provisions  when  they  are  outlined,  not  to  identify  all  potential  provi- 
sions. For  the  same  reason,  the  organizational  tree  need  not  be  a complete 
representation  of  the  classification.  It  is  conceivable  that  a single  facet 
could  lead  to  a useful  ordering  of  a set  of  provisions.  However,  the  orga- 
nization must  provide  a location  for  each  existing  provision. 

With  these  points  in  mind,  the  classifier-driven  technique  described  in  the 
preceding  section  "use  in  synthesis"  can  be  used  to  generate  alternative, 
or  trial,  organizations  for  an  existing  standard,  and  these  organizations 
examined  for  the  qualities  discussed  at  the  beginning  of  this  section.  It 
should  be  noted,  however,  that  when  the  outline  is  subsequently  generated, 
the  majority  of  the  branches  in  the  organizational  tree  likely  will  be 
found  not  to  have  any  provisions  associated  with  them.  This  point  is  dis- 
cussed further  in  section  4.6. 

4.5.2  Proper  Usage 

Proceed  from  small  to  big.  It  is  best  to  enter,  examine,  and  modify 
smaller  organizations  corresponding  to  various  grouping  of  facets  before 
entering  an  organization  for  an  entire  version. 

Use  as  "template"  for  outlining.  Since  fewer  decisions  are  required  for 
generating  an  organization  than  for  generating  an  outline,  it  is  advisable 
to  experiment  with  several  organizations  before  proceeding  to  building  a 
complete  outline. 
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4.5.3  Representation 

In  SASE,  an  organization  is  generated  by  the  ENTER  ORGANIZATION  command. 
(It  can  also  be  generated  concurrently  with  an  outline.  See  section  4.6.) 
Since  there  may  be  alternative  organizations  within  a VERSION  of  a stand- 
ard, the  organization  is  given  a reference  number. 

The  organization  is  built  in  a dialogue  form.  For  each  line  of  input,  the 
user  specifies  a classifier  to  serve  as  the  heading,  and  the  hierarchical 
position  of  that  heading  on  the  organization  tree.  For  the  latter,  two 
options  are  provided: 

• if  the  LEVEL  qualifier  is  used  in  the  command,  the  user  directly 
specifies  the  hierarchical  level  to  be  assigned  to  the  classifier 
entered. 

• if  the  PARENT  qualifier  is  used  in  the  command,  the  user  enters  the 
heading  number  previously  assigned  to  the  parent  of  the  classifier 
entered;  SASE  automatically  assigns  a hierarchical  level  to  the 
classifier  equal  to  the  parent's  level  plus  one. 

Entry  by  the  PARENT  option  is  recommended,  as  this  is  the  only  way  to 
ensure  that  the  hierarchical  relation  of  the  nuclear  trees  is  properly 
reflected  in  the  organization. 

Since  entry  of  a sizeable  classification  is  time-consuming,  the  user  can 
END  the  dialogue  to  any  time  and  resume  entry  using  the  CONTINUE  ORGANIZA- 
TION command. 

The  MODIFY  ORGANIZATION  permits  various  rearrangements,  including: 

• INSERTing  specific  headings  by  LEVEL  or  PARENT,  as  above; 

• DELETing  a specific  heading  or  a set  of  headings; 

• DUPLICATing  or  MOVing  a specific  heading  or  set  of  headings  to  a 
specified  position. 

• MODIFYing  a specific  classifier,  its  level  or  its  parent  in  the 
organization. 

The  DISPLAY  ORGANIZATION  command  provides  a number  of  options  for  display- 
ing an  organization: 

• the  display  can  be  in  indented  or  tabular  form; 

• the  tabular  form  can  include  any  attributes  of  the  classifiers 
serving  as  headings . 
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4 . 6 Outline 


4.6.1  Definition 

An  outline  is  a list  representation  of  the  scope  of  a standard.  It  consists 
of  a hierarchical  arrangement  of  the  classifiers  as  headings  of  sections 
(i.e.,  an  organization)  with  the  provisions  of  the  standard  entered  under 
the  appropriate  headings . 

The  goal  for  the  process  of  outlining  a standard  is  to  find  the  best  linear 
order  of  the  provisions  in  the  list- -the  order  that  maximizes  the  desired 
qualities  of  organization  described  in  section  4.5.  Outlining  differs  from 
indexing  in  the  necessity  for  logical  rigor.  Because  an  outline  is  in- 
tended to  provide  a single  point  of  access  for  every  provision,  logical 
unambiguity  is  more  important  than  it  is  for  indexing,  in  which  classing  a 
provision  by  two  siblings  is  acceptable.  (Note  that  the  outlining  process 
does  not  guarantee  that  a provision  will  appear  only  once  in  the  outline; 
this  problem  is  taken  up  in  the  discussion  of  provision  entry.) 

The  approach  advocated  here  involves  two  activities: 

1,  Generating  alternative  outlines  with  strategies  that  promote  the 
desirable  qualities. 

2.  Measuring  the  qualities  of  different  outlines  to  compare  their 
overall  goodness  for  the  specific  intended  use. 

This  approach  has  the  advantage  of  being  able  to  provide  different  outlines 
of  the  same  provisions  for  different  users.  Only  the  generation  of  the 
outlines  is  discussed  in  this  report.  Much  of  the  basis  for  preference  of 
one  outline  over  another  is  individual  and  subjective;  hence,  little  guid- 
ance can  be  given  on  measuring  the  quality  of  an  outline.  A discussion  of 
several  useful  measures  is  presented  in  [9]. 

The  generation  of  an  outline  from  a classification  for  a set  of  provisions 
logically  proceeds  in  two  steps:  first,  an  organizational  tree  is  generated 
by  appending  nuclear  trees  of  classifiers  together,  then  provisions  are  en- 
tered on  the  branches  of  the  tree  according  to  their  arguments.  In  SASE, 
these  steps  can  be  taken  separately  by  first  generating  an  organization 
from  the  classification,  as  described  in  section  4.5,  and  then  generating 
an  outline  from  it,  or  the  steps  can  be  taken  together  in  an  interactive 
input  mode  to  generate  an  outline  (including  its  organization)  directly 
from  the  classification. 

The  techniques  of  creating  an  outline  are  discussed  in  more  detail  in  the 
following  two  subsections.  First,  the  methods  for  generating  organiza- 
tional trees  are  reviewed;  then,  criteria  for  entry  of  a provision  on  a 
branch  of  an  organizational  tree  are  discussed. 

Generation  of  organizational  trees , The  rules  for  appending  nuclear  trees 
to  an  organizational  tree  described  in  section  4.5  can  be  modified  when  the 
goal  is  the  generation  of  an  outline  for  existing  provisions.  Now  two 
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different  criteria  are  available  for  making  the  decision  to  cease  the 
extension  of  a branch  and  move  on  to  the  next  branch:  the  absence  of  any 
qualified  nuclear  trees  or  the  absence  of  an  eligible  provision.  The  first 
criterion  was  used  in  the  classifier-driven  technique  presented  in  section 
4.5.  Classifier-driven  techniques  allow  one  to  maintain  the  completeness  of 
the  classification  system  in  the  organizational  tree,  and  thus  to  check  the 
completeness  of  the  provisions.  However,  nearly  all  techniques  for  gener- 
ating outlines  for  an  existing  set  of  provisions  make  use  of  the  second 
criterion;  they  may  be  termed  "provision  driven."  Classifier-driven 
techniques  are  not  often  used  for  expression  of  existing  standards  because 
the  resulting  organizational  trees  are  extremely  large  and  the  majority  of 
their  branches  do  not  have  provisions  associated  with  them. 

The  reason  that  classifier-driven  techniques  develop  so  many  empty  branches 
is  that  the  assumption  of  independence  between  the  fields  is  not  warranted. 
Consider  the  analysis  of  the  seismic  provisions  [18],  and  the  classifica- 
tion system  for  it  given  in  figure  4.3.  If  the  21  facets  in  the  "Physical 
Entity"  field  were  independent  (obviously  they  are  not,  nor  are  they  as- 
sumed so)  an  organizational  tree  fully  incorporating  all  of  them  would  have 
over  three  billion  branches  (the  product  of  the  terminal  branches  of  the  21 
facets) . The  most  conservative  estimate  for  the  number  of  branches  in  an 
organizational  tree  for  that  classification  would  proceed  as  follows: 
assume  that  the  "Physical  Entity"  field  is  one  tree  with  no  interaction  (a 
false  assvimption)  , thus  having  62  branches  (the  sum  of  the  terminal  classi- 
fiers of  its  facets)  , and  assume  that  the  21  branches  of  the  "Process" 
field  (not  shown)  combines  additively,  not  multiplicatively , with  it  to 
give  all  THINGS  possible  for  subjects  of  Requirements  (also  a false  assump- 
tion). Ignoring  other  possible  fields,  estimate  the  total  number  of 
branches  as  the  product  of  the  12  branches  of  the  REQUIRED  QUALITY  field 
(also  not  shown)  and  the  79  branches  of  the  combined  subject  fields.  The 
total  thus  obtained  is  948,  whereas  the  total  number  of  requirements  found 
in  that  study  is  242.  It  does  not  appear  that  the  number  would  approach 
948.  The  assiomption  regarding  the  "Physical  Entity"  field  having  only  62 
branches  is  quite  extreme.  Thus,  a more  realistic  assumption  would  result 
in  a number  of  branches  far  in  excess  of  948. 

The  drastic  pruning  of  the  branches  of  the  actual  organizational  tree 
compared  to  the  complete  tree  occurs  because  there  are  many  situations  in 
which  it  is  correct  to  append  only  a portion  of  a nuclear  tree,  leaving 
some  of  the  siblings  off  the  organizational  network.  Provision-driven 
techniques  allow  this . 

A problem  that  arises  in  generating  an  organizational  tree  for  outlining 
purposes  is  that  some  provisions  are  of  a more  general  nature  than  others, 
and  therefore  strict  application  of  the  Graded  criterion  for  provision 
entry  frequently  will  prevent  the  entry  of  the  more  general  provisions  in 
an  organizational  tree.  It  is  possible  to  overcome  this  problem  by  expand- 
ing the  classification  system.  Such  was  the  reason  for  including  the  facet 
"Material  Nature"  with  the  sons  "Material  Generic"  and  "Material  Specific" 
in  the  classification  for  the  seismic  provisions  (figure  4.3).  This  small 
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facet  was  appended  in  conjunction  with  the  material  types  thus: 

Material  Generic 
Material  Specific 
Wood 
Steel 
Concrete 
Masonry 

This  allowed  otherwise  identical  branches  to  be  constructed  so  that  both 
general  and  specific  provisions  could  be  outlined  without  forcing  "Wood," 
"Steel,"  and  so  forth,  to  become  siblings  of  other  classifiers  to  which 
they  were  logically  unrelated. 

Entry  of  provisions  in  an  organizational  tree.  Entry  depends  upon  the  com- 
parison of  the  set  of  classifiers  that  compose  a branch  of  an  organiza- 
tional tree  with  the  set  of  outlining  arguments  for  a provision.  The 
comparison  reveals  whether  the  provision  is  appropriately  identified  by  the 
classifiers  on  the  branch.  The  decision  to  enter  a provision  is  based  on 
four  criteria  which  follow  from  the  qualities  necessary  for  an  effective 
organization  of  a standard  (see  section  4.5)  as  follows: 

1.  Relevant:  each  classifier  on  the  branch  must  be  related  to  one  of 

the  provision's  outlining  arguments. 

2.  Complete:  each  outlining  argument  of  the  provision  must  be  in- 

cluded among  the  set  of  classifiers  on  the  branch. 

3.  Unique:  no  classifier  on  the  branch  may  be  a "cousin"  (This  con- 

cept is  defined  subsequently)  of  any  outlining  argument. 

4.  Graded;  no  classifier  on  -the  branch  may  be  a descendant  of  any 
outlining  argument. 

The  decision  does  not  depend  on  the  desirable  qualities  Even,  Minimal,  and 
Progressive  because  they  are  not  relevant  in  the  context  of  a single  branch 
of  an  organizational  tree.  The  quality  Meaningful  is  achieved  automatically 
the  arguments  for  each  provision  have  been  selected  properly.  It  is  possi- 
ble to  consider  a limit  on  the  number  of  nodes  on  a branch  as  a criterion 
for  the  quality  Intelligible. 

Each  of  the  four  criteria  depends  on  the  logic  of  the  classification  sys- 
tem. Since  a faceted  classification  system  need  not  be  strictly  logical, 
checking  of  the  criteria  becomes  complex.  As  mentioned  in  section  4.2,  it 
is  possible  to  combine  all  the  facets  in  a field  into  a single  large  facet, 
but  frequently  it  is  also  possible  to  combine  the  facets  in  a relevant 
fashion  into  a large  tree  that  is  not  completely  logical.  The  problem  is 
to  define  clearly  how  the  qualities  can  be  attained  with  a less  than  per- 
fectly logical  classification  system. 

Given  a faceted  system,  the  criterion  for  the  quality ' Relevant  is  easily 
described  in  three  steps.  Each  classifier  on  the  branch  must  pass  the 
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criterion  for  the  provision  in  question  to  qualify  for  entry  on  the  branch. 
The  three  steps  are: 

1.  A classifier  that  is  an  argument  of  the  provision  is  relevant. 

2.  A classifier  from  the  same  facet  as  an  argument  is  relevant  if  it 
is  a logical  predecessor  of  the  argument.  (A  logical  predecessor 
is  the  parent,  the  parent  of  the  parent,  etc.) 

3.  A classifier  from  the  same  field,  but  not  the  same  facet,  as  an 
argument  is  relevant  if  it  is  a logical  predecessor  of  the  argu- 
ment in  a large  tree  of  combined  facets. 

The  second  test  can  be  extended  to  say  that  a classifier  from  the  same 
facet  as  an  argument  is  not  relevant  unless  it  is  a predecessor  of  the 
argument  (assuming  it  failed  the  first  test) . Making  this  extension  means 
that  the  criteria  for  the  qualities  Unique  and  Graded  mentioned  previously 
are  automatically  included,  as  far  as  facets  are  concerned.  As  shown  in 
figure  4.7,  there  are  four  possibilities  for  a classifier  and  an  argument 
from  the  same  facet:  the  classifier  is  a predecessor,  descendent,  or 

cousin  of  the  argioment  or  is  the  same  as  the  argument.  As  shown  in  figure 
4,7,  a cousin  includes  the  siblings,  the  siblings  of  the  predecessors,  and 
any  descendants  of  such  siblings.  The  third  test  for  the  quality  Relevant 
cannot  be  similarly  extended,  (that  is,  it  cannot  be  used  to  disqualify  a 
provision  simply  because  one  classifier  fails  the  test) , because  the  possi- 
bility of  illogical  siblings  leaves  the  possibility  that  the  classifier  may 
be  relevant  for  another  argument  for  the  same  provision. 

The  principal  problem  in  using  these  tests  for  the  quality  Relevant  is  that 
a complete  specification  of  the  permissible  interconnections  of  the  facets 
is  required  as  a part  of  the  classification  system.  Otherwise  a poten- 
tially relevant  classifier  that  is  not  traceable  to  any  argument  will 
disqualify  a provision  from  appearance  on  the  appropriate  branch.  A system 
for  recording  and  using  relations  between  facets  is  included  in  SASE. 

An  added  problem  is  that  the  tracing  of  the  permissible  interconnections 
among  facets  involves  significantly  more  checking  than  any  other  tests 
employed  for  entry  of  a provision  on  a branch. 

There  is  a less  stringent  criterion  for  the  quality  Relevant  that  fre- 
quently is  good  enough  to  produce  useful  outlines.  The  criterion  combines 
well  with  the  relatively  simple  criteria  for  the  qualities  Unique  and 
Graded,  which  tend  to  prevent  irrelevance  in  addition  to  delivering  their 
named  objectives.  The  criterion  is  quite  simple:  the  last  classifier  on 

the  branch  must  be  an  argument  of  the  provision.  It  is  accomplished  effi- 
ciently by  selecting  those  provisions  in  the  scope  list  of  the  last  classi- 
fier and  discarding  all  others.  Since  it  is  the  last  classifier  on  the 
branch,  it  also  has  the  desirable  feature  of  limiting  the  provisions  to  be 
checked  by  the  other  criteria  in  an  intuitively  optimal  fashion.  For 
convenience,  this  less  stringent  criterion  is  called  "local  relevance." 
Useful  outlines  may  be  obtained  employing  the  local  relevance  criterion 
without  any  of  the  other  criteria.  Methods  of  synthesizing  organizational 
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Figure  4.7  Partition  of  a tree  into  logical  regions. 
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trees,  described  in  section  4.5,  tend  to  promote  the  validity  of  the  local 
relevance  criterion. 

The  criterion  for  the  quality  Complete  assures  that  a provision  is  not 
prematurely  entered  into  an  outline.  It  has  nothing  to  do  with  assuring 
that  all  provisions  are  outlined,  another  aspect  of  completeness.  The 
criterion  is  independent  of  the  question  of  relevance,  and  it  is  applied 
conveniently  immediately  following  the  local  relevance  criterion.  For  each 
provision  passing  the  local  relevance  criterion,  a check  is  made  to  see 
that  each  of  its  arguments  is  among  the  classifiers  on  the  branch. 

A separate  check  for  the  quality  Unique  at  the  facet  level  often  is  useful 
when  the  full  relevance  criterion  is  not  employed.  The  criterion  disquali- 
fies any  provision  with  an  argument  that  is  a cousin  of  one  of  the  classi- 
fiers on  the  branch. 

A separate  check  for  the  quality  Graded  at  the  facet  level  often  is  also 
useful  when  the  full  relevance  criterion  is  not  employed.  The  test  is 
convenient  to  apply  in  conjunction  with  the  Unique  criterion  just  describ- 
ed, because  of  the  nature  of  the  task  of  partitioning  a tree  as  shown  in 
figure  4,7,  Redundant,  therefore  ambiguous,  locations  for  provisions  may 
be  a common  defect  in  outlines  developed  without  use  of  the  graded  crite- 
rion, Because  logic  is  not  preserved  above  the  facet  level  it  is  not 
possible  to  apply  criteria  for  Unique  or  Graded  above  that  level, 

A common  defect  in  an  outline  that  satisfies  all  the  criteria  except  full 
relevance  is  the  entry  of  a single  provision  on  more  than  one  branch  of  the 
organizational  tree.  The  ambiguity  usually  arises  from  the  use  of  a facet 
that  is  not  exhaustive,  (A  facet  is  exhaustive  if  its  combined  scope  list 
includes  all  provisions,)  For  example,  consider  a provision  from  the 
analysis  of  the  seismic  provisions  for  buildings  with  the  arguments:  "Part 
of  Building,"  "Material  Specific,"  and  "Masonry,"  It  would  meet  all  crite- 
ria except  full  relevance  for  both  of  the  following  branches  of  classi- 
fiers : 


(i) 


(ii) 


Part  of  Building 
Structural 
Material  Specific 
Masonry 


Part  of  Building 
Nonstructural 
Material  Specific 
Masonry 


The  problem  is  that  Structural  and  Nonstructural  are  not  exhaustive;  the 
provision  could  apply  to  either.  Using  the  full  relevance  criterion,  the 
provision  would  not  qualify  for  either  branch. 


Even  the  full  relevance  criterion  is  not  guaranteed  to  prevent  all  redun- 
dant entry  of  provisions,  unless  the  fields  are  strictly  logical.  Consider 
the  same  provision  just  described  and  the  following  branches  of  classi- 
fiers : 
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(i) 


(ii) 


Part  of  Building  Part  of  Building 

Material  Specific  Material  Specific 

Component  Masonry 

Masonry 

"Component"  belongs  to  a facet  that  can  be  used  to  distinguish  among  var- 
ious "Parts  of  Buildings",  and  "Masonry"  belongs  to  a facet  that  may  be 
used  to  distinguish  among  various  "Components."  The  former  fact  means 
"Component"  is  not  out  of  place  in  the  branch,  and  the  latter  fact  means 
that  "Component"  can  be  a predecessor  of  "Masonry,"  thus  satisfying  the 
full  relevance  criterion.  Since  "Component"  is  not  an  argiiment,  the  com- 
pleteness criterion  is  satisfied  for  either  branch.  Thus  the  provision 
qualifies  for  both  branches- -an  ambiguous  situation. 

Three  possible  solutions  for  this  problem  exist.  The  first  possible  solu- 
tion is  to  enforce  the  logical  rules  for  the  entire  classification.  For 
reasons  already  explained,  however,  fully  logical  classifications  are  not 
always  desirable  or  possible. 

The  second  possible  solution  is  to  strengthen  the  full  relevance  criterion 
by  requiring  that  each  of  the  classifiers  on  the  branch  be  an  argximent  or 
the  direct  predecessor  (within  the  same  facet)  of  an  argument.  This  would 
avoid  tracing  the  relations  between  facets.  It  has  the  disadvantage  of 
requiring  added  identification  and  storage  of  arguments.  For  example, 
consider  the  following  five  arguments  for  a requirement  giving  the  minimum 
amount  and  spacing  of  reinforcement  in  a cased  concrete  pile: 

Pile,  Reinforced  Concrete,  Cased, 

Reinforcement,  Quantities  and  Dimensions 

With  the  exception  of  "Quantities  and  Dimensions,"  which  is  a child  of 
"Required  Quality,"  these  arguments  appear  in  the  physical  entity  field 
shown  in  figure  4.3.  Now,  consider  the  application  of  the  strengthened 
relevance  criterion  against  the  following  list  of  classifiers  which  clearly 
represents  an  appropriate  branch  for  the  provision  (compare  figure  4.3): 


Building 

- does  not  qualify 

Required  Quality 

- direct  predecessor 

of 

"Quantities 

and  Dimensions" 

Part  of  Building 

- does  not  qualify 

Structural 

- does  not  qualify 

Foundation 

- does  not  qualify 

Foundation  Structure 

- direct  predecessor 

of 

"Pile" 

Pile 

- is  an  argument 

Quantities  and  Dimensions 

- is  an  argument 

Reinforcement 

- is  an  argument 

Reinforced  Concrete 

- is  an  argument 

Cast- in-place 

- direct  predecessor 

of 

"Cased" 

Cased 

- is  an  argument 
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The  requirement  fails  to  qualify  for  this  branch  based  on  the  strengthened 
criterion.  The  addition  of  "Foundation"  as  an  argument  for  the  requirement 
would  qualify  "Foundation"  trivially  and  "Structural"  because  it  is  a 
direct  predecessor.  The  addition  of  "Part  of  a Building"  as  an  argument 
would  qualify  "Part  of  Building"  and  "Building"  in  like  fashion.  The  re- 
quirement would  then  pass  the  strengthened  criterion.  For  this  provision, 
it  is  not  a large  problem  to  add  two  arguments,  but  it  could  be  for  others. 
Furthermore,  it  seems  redundant  because  the  argument  "Pile"  clearly  implies 
that  all  of  those  higher  order  classifiers  are . relevant . 

The  third  possible  solution  is  to  develop  a more  complete  and  explicit  set 
of  rules  for  tracing  the  relations  among  facets.  One  such  test  not  includ- 
ed in  the  present  system  is  to  require  that  the  argument  indirectly  related 
to  the  classifier  must  follow  that  classifier  (not  necessarily  immediately) 
on  the  branch.  Another  is  that  the  branch  of  classifiers  contain  at  least 
one  classifier  from  each  facet  involved  in  the  linkage. 

Given  that  the  relevance  criterion  is  divided  into  two  criteria,  local  and 
full,  and  that  the  full  relevance  criterion  will  not  always  be  used,  an 
efficient  strategy  for  computer  processing  emerges: 

1.  Apply  the  local  relevance  criterion. 

2.  For  each  provision  passing  the  local  relevance  criterion,  test 
each  argument  for  the  Complete,  Unique,  and  Graded  criteria,  in 
that  order. 

3.  For  each  provision  passing  those  criteria,  test  each  of  the  set  of 
classifiers  for  the  full  relevance  criterion,  di£>qualifying  the 
provision  if  any  classifier  fails.  The  full  relevance  criterion 
is  actually  applied  in  three  steps,  repeated  here  for  convenience: 
the  classifier  is  relevant  if  it  is  an  argument  or  it  if  it  is  a 
logical  predecessor  of  an  argument,  either  within  or  outside  the 
same  facet. 

Such  an  approach  is  included  in  SASE.  The  application  of  all  three  crite- 
ria is  optional:  testing  may  stop  after  any  criterion,  if  desired. 

A recommended  strategy  is  to  begin  outlining  using  all  criteria  relaxing 
the  application  of  the  later  criteria  if  logical  problems  seem  to  preclude 
the  development  of  outlines  that  can  include  all  the  provisions.  The 
alternate  strategy  of  beginning  to  outline  without  the  more  rigorous  cri- 
teria, and  resorting  to  them  only  if  necessary  to  reduce  the  redundant 
occurrences  of  provisions  has  the  advantage  of  less  costly  computer  proces- 
sing, but  it  has  the  disadvantage  of  letting  irrelevant,  and  sometimes 
illogical,  outlines  be  developed. 

In  summary,  two  independent  criteria- -Relevant  and  Complete -- lead  to  five 
criteria  that  work  in  a faceted  classification  system:  local  relevance. 

Complete,  Unique,  Graded,  and  full  relevance.  It  is  possible  to  develop 
good  outlines  without  using  all  the  criteria,  but  ambiguities  and  inconsis- 
tencies are  less  likely  when  using  all  the  criteria.  Because  it  still  is 
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possible  to  develop  outlines  with  more  than  one  position  for  a provision 
when  using  all  the  criteria,  more  study  of  the  fifth  criterion  and  of  the 
logic  of  faceted  systems  is  in  order. 

The  development  of  an  algorithm  capable  of  automatically  and  completely 
generating  an  organizational  tree  and  outline  in  a provision-driven  mode 
and  with  a faceted  classification  system  appears  to  be  a formidable  task. 
SASE  contains  a semi-automatic,  interactive  computer  algorithm.  With 
respect  to  the  criteria  for  appending  nuclear  trees  presented  earlier  in 
this  section,  the  algorithm  operates  as  follows: 

1.  Relevant:  no  explicit  check  is  made 

2.  Unique:  appending  more  than  one  nuclear  tree  to  a single  node  is 

possible,  but  only  on  explicit  command  of  the  user. 

3.  Graded:  no  explicit  check  is  made. 

4.  Complete:  no  explicit  check  is  made  in  most  situations -- this  is 

not  a classifier  driven  algorithm. 

5.  Progressive:  the  normal  order  of  the  classification  is  automatic, 

although  it  is  possible  for  the  user  to  override  it. 

6.  Minimal:  the  order  of  appending  is  completely  up  to  the  user. 

The  lack  of  explicit  checks  for  Relevant  and  Graded  is  not  intended  to 
imply  that  they  are  thought  unnecessary.  Rather,  their  incorporation  is 
advocated.  They  are  not  in  the  present  SASE  computer  algorithm  only  because 
the  algorithm  was  developed  to  test  various  criteria  for  provision  entry 
rather  than  nuclear  tree  appending.  A test  for  Relevant  may  be  more  prob- 
lematic, as  discussed.  Various  criteria  should  be  tested  for  workability, 
because  incorporation  of  such  a test  would  be  an  important  step  in  the 
development  of  a completely  automatic  algorithm. 

The  interactive  algorithm  is  provision  driven.  Once  the  user  has  entered  a 
branch,  the  algorithm  determines  which  provisions  have  the  potential  to  be 
outlined  on  the  branch  should  additional  classifiers  be  appended  to  it. 
The  algorithm  will  also  specify  those  classifiers  upon  request.  The  user 
then  continues  by  either  appending  another  nuclear  tree,  or  moving  on  to 
the  next  branch. 

4.6.2  Proper  Usage 

First  develop  a satisfactory  organization  (see  section  3.5).  Even  with  an 
organization  as  a "template"  the  user  must  proceed  thoughtfully  to  obtain 
the  desired  qualities  for  an  outline.  A logically  unambiguous  location  must 
be  provided  in  the  outline  for  each  provision. 
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4.6.3  Representation 

In  SASE,  an  outline  is  generated  by  the  GENERATE  OUTLINE  command.  Since 
there  can  be  only  one  outline  within  a VERSION  of  a standard,  the  outline 
does  not  have  an  explicit  reference  number. 

There  are  two  basic  options  for  generating  an  outline: 

• FROM  a previously  entered  ORGANIZATION-;  or 

• STEPWISE,  in  a dialogue  form  similar  to  ENTER  ORGANIZATION. 

The  user  can  further  specify: 

• whether  ALL  classifiers  are  to  appear  in  the  outline  or  only  those 
with  relevant  provisions; 

• whether  all  data  items  are  to  be  included  or  only  REQUIREMENT  or 
DETERMINATION; 

• DROPping  specified  CLASSIFIERS,  FIELDS,  or  FACETS  from  the  outline; 
and 

• criteria  for  ENTRY  (see  above) . 

In  the  STEPWISE  option,  each  heading  (classifier)  and  its  associated  provi- 
sions (data  items)  are  generated  in  two  cycles  of  the  dialogue: 

• the  user  first  enters  a classifier  to  serve  as  the  heading  and  its 
hierarchical  level  in  the  outline  (the  heading  may  be  a specific 
CLASSIFIER  or  indirectly  a descendant  of  a specified  PARENT) ; 

• the  user  specifies  the  provisions  meeting  the  ENTRY  criterion  to  be 
entered  under  the  heading;  alternately,  the  user  can  first  ask  SASE 
to  LIST  the  qualified  candidate  provisions  and  then  specify  the 
ones  to  be  entered. 

Since  generated  of  a sizeable  outline  is  time-consuming,  the  user  can  END 
the  dialogue  at  any  time  and  resume  generation  using  the  CONTINUE  OUTLINE 
command . 

The  DISPLAY  OUTLINE  command  provides  a number  of  options  for  displaying  an 
outline : 

• the  display  can  be  indented  or  tabular  form; 

• ALL  or  only  specified  classifier  attributes  can  be  included; 

• ALL  data  items  or  only  REQUIREMENTS  or  DETERMINATIONS  can  be  in- 
cluded under  each  classifier;  and 

• ALL  or  only  specified  data  item  attributes  can  be  included. 
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APPENDIX  A.  ANALYSIS  OF  A STANDARD  FOR  CONCRETE  QUALITY 


A . 1 Introduction 

To  provide  a practical  demonstration  of  the  SASE  methodology  for  the  ra- 
tional analysis  and  expression  of  standards,  the  results  of  a study  of  a 
standard  for  concrete  quality  are  presented  in  this  appendix.  The  subject 
standard  comprises  all  of  Chapter  4,  "Concrete  Quality",  of  the  American 
Concrete  Institute's  Building  Code  Requirements  for  Reinforced  Concrete 
CACI  318-77)  [1]  . Virtually  all  of  the  SASE  techniques  for  analyzing  and 

expressing  a standard  were  applied  in  the  study. 

A. 2 Technical  approach 

The  study  was  conducted  in  the  order  of  the  steps  for  the  rational  analy- 
sis and  expression  of  an  existing  standard  described  in  Chapters  3 and  4 of 
this  report.  In  stimmary,  these  steps  are  to; 

1.  identify  the  derived  (requirements  and  determinations)  and  input 
data  items  in  the  text  of  the  standard; 

2.  develop  decision  tables  to  model  the  logic  of  the  requirements  and 
determinations ; 

3.  develop  a global  ingredience  network  systematically  linking  the 
requirements  and  determinations  contained  in  the  standard; 

4.  classify  the  requirements  and  determinations  to  determine  the 
scope  of  the  standard  and  for  outlining  and  indexing  the  contents; 
and 

5.  organize  logically  the  contents  of  the  standard. 

As  described  in  Chapter  1 of  this  report,  reviewing  the  subject  matter  with 
experts  during  the  course  of  analysis  and  expression  was  found  in  the  study 
to  be  essential.  Such  interaction  was  especially  valuable  wherever  multi- 
ple interpretations  of  the  text  seemed  possible,  and  where  SASE  analysts 
noted  the  text  of  the  standard  to  be  ambiguous  or  incomplete.  Particularly 
important  times  for  interaction  between  subject  matter  experts  and  SASE 
analysts  were:  (1)  after  requirements  and  determinations  had  been  (tenta- 

tively) identified  and  a draft  ingredience  network  had  been  developed,  and 
(2)  while  draft  organizational  outlines  were  being  developed. 

A. 3 Results 

The  results  are  presented  in  this  section  in  the  same  order  as  the  steps 
taken  in  the  study.  The  figures  and  tables  discussed  in  this  section  are 
grouped  at  the  end  of  the  appendix  for  easy  reference. 
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A.  3.1  Data  items 


The  text  of  the  standard  for  concrete  quality,  indicating  the  location  of 
individual  data  items  (annotated  with  datum  reference  number;  see  section 
A. 3. 3 below),  is  shown  in  figure  A.l.  The  derived  data  items  are  listed  in 
SASE- format  in  figure  A.  2 and  the  input  data  items  are  listed  in  SASE- 
format  in  figure  A.  3.  The  notation  used  includes  (see  Chapter  3 of  this 
report) : 

REFE:  datum  reference  number  (numbers  below  1000  denote  derived  data 

items;  those  above  denote  input  data  items). 

NAME:  a datum  identifier. 

SECT:  section  of  the  standard  containing  the  datum  (delimiting  pe- 

riods omitted) . 

PAGE:  page  of  Chapter  4 of  the  standard  containing  the  datum. 

VALU:  boolean  for  requirements;  boolean,  boolean  vector,  or  numeric 

for  determinations. 

SOUR:  source  of  the  datum,  i.e.,  either  input  or  derived. 

TYPE:  type  of  datum,  i.e.,  either  decision  table  or  function. 

STAT:  either  classified  (linked  with  at  least  one  classifier)  or 

unclassified. 

UTIL:  utilization  of  the  datum,  i.e.',  either  requirement  or  determi- 

nation. 

TITL:  text  string  providing  a descriptive  title  of  the  datum. 

INGREDIENTS:  reference  numbers  of  data  items  ingredient  to  the  datum, 

or  data  items  upon  which  the  datum  is  dependent. 

ARGUMENTS:  reference  numbers  of  classifiers  linked  to  the  datum. 

EQUIVALENTS:  cross  references  with  other  data  items,  by  datum  refer- 

ence numbers  (not  used  in  the  present  example) . 

COMMENT:  text  string  containing  explanatory  information. 

The  distribution  of  the  data  items  in  the  standard  (see  figure  A.l)  shows 
that  the  text  is  not  uniformly  complex.  The  subdivision  of  the  text  into 
numbered  paragraphs  implies  that  each  paragraph  is  a discrete  unit  of 
information.  In  some  instances,  there  is,  in  fact,  a one-to-one  correspon- 
dence between  a datum  and  a mombered  paragraph.  On  the  other  hand,  in  some 
instances,  several  data  items  correspond  to  a single  numbered  paragraph, 
and,  in  some  instances,  a datum  corresponds  to  an  entire  major  heading 
encompassing  several  numbered  paragraphs. 
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A. 3. 2 Decision  Tables 


Any  datum  of  type  REQUIREMENT  may  be  expressed  as  a decision  table,  and 
with  the  use  of  this  aid  may  be  analyzed  for  completeness  and  clarity.  The 
general  form  for  a decision  table  representation  of  a datum  is  discussed  in 
section  3.3  of  this  report.  The  decision  table  for  a requirement  datum 
specifies  a set  of  conditions  (each  of  which  may  be  true,  false,  or  irrele- 
vant during  the  evaluation  of  the  datum),  combinations  of  which  (i.e., 
rules)  yield  either  of  two  actions:  that  the  requirement  is  satisfied  or 
violated.  In  practice,  requirements  with  only  a single  condition  fre- 
quently are  found  in  the  text  of  a standard.  One  example  found  in  the  text 
of  figure  A.l  is:  "Requirement  for  the  specification  of  concrete  strength 
on  design  drawings,"  datum  reference  number  10.  The  single  condition  here 
is  whether  or  not  concrete  strength  has  in  fact  been  specified  on  the 
drawings.  If  it  has,  then  the  requirement  is  satisfied.  If  not,  then  the 
requirement  is  violated.  The  analysis  of  such  a requirement's  completeness 
and  clarity  would  not  be  enhanced  by  the  development  of  a decision  table. 
For  this  reason,  decision  tables  were  developed  in  this  study  only  for  data 
items  with  two  or  more  conditions. 

Data  items  of  type  DETERMINATION  also  may  be  expressed  as  decision  tables. 
Unlike  tables  for  REQUIREMENT  data  items,  however,  rules  in  DETERMINATION 
tables  may  yield  actions  that  return  numerical  or  nominal  values.  An  exam- 
ple is  the  "determination  of  standard  deviation,"  datum  reference  number 
70.  In  this  example,  rules  1 and  2 yield  the  nominal  scalar  value:  "stand- 
ard deviation  computed  by  statistics."  The  standard  deviation  is  not  de- 
fined for  any  other  rule. 

Once  entered  in  SASE,  the  decision  tables  were  analyzed  by  generating 
decision  trees.  This  analysis  checked  the  decision  tables  for  logical 
consistency.  In  addition,  this  analysis  determined  explicitly  the  else 
rules  associated  with  each  decision  table.  A list  of  all  possible  combina- 
tions of  conditions  leading  to  the  else  rule  in  a decision  table  is  very 
helpful  to  the  SASE  analyst  in  determining  whether  the  corresponding  provi- 
sion is  complete  in  its  scope.  The  decision  tables  for  the  standard  for 
concrete  quality  are  presented  in  SASE-format  in  tables  A.l  to  A. 11,  along 
with  their  associated  tables  of  else  rules  as  generated  by  SASE. 

A. 3. 3 Global  ingredience 

Once  the  individual  data  items  were  entered  into  SASE  along  with  their 
ingredient  data  items,  the  global  ingredience  network  was  generated  to 
thread  all  the  data  items  together.  Figure  A. 4 displays  the  global  ingre- 
dience network  for  the  standard  for  concrete  quality  arranged  in  order  of 
the  requirements . 

An  exploded  segment  of  the  global  ingredience  network  is  displayed  in 
figure  A.  5 to  provide  a guide  to  the  interpretation  of  a SASE-generated 
network.  Datum  181  is  the  only  output  requirement  in  this  segment  and  lies 
at  level  0 in  the  network.  Datum  182  is  a direct  ingredient  of  this  output 
requirement  and  lies  at  level  1.  Datum  60  is  also  a direct  ingredient  of 
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the  output  requirement  but,  perhaps  counter-intuitively,  it  lies  at  level 
2.  A property  of  the  algorithm  that  displays  networks  in  SASE  is  that  first 
the  innermost  level  at  which  each  datum  lies  anywhere  in  the  network  is 
determined  and  then  each  datum  is  displayed  at  this  innermost  level  every- 
where it  appears  in  the  network.  Thus,  datum  60,  which  is  a direct  ingre- 
dient of  the  output  requirement  lies  at  level  2 in  the  network  because  that 
is  the  innermost  level  it  occupies  as  a consequence  of  being  a direct 
ingredient  of  dattim  182  also.  This  level- spanning  property  of  the  display 
algorithm  results  in  a network  that  is  easier -for  a SASE  analyst  to  assess 
in  terms  of  flows  of  information. 

Figure  A.  5 also  illustrates  the  SASE  notation  for  network  entries.  The 
reference  number  in  the  second  (and  any  following)  occurance  of  datum  60  is 
preceded  by  a minus  (-)  sign  to  indicate  that  this  datum  has  occured  before 
in  the  display  of  the  network.  The  asterisk  (*)  following  the  reference 
number  in  its  second  (and  any  following)  occurance  indicates  that  datum  60 
has  ingredient  data  items  and  that  these  have  been  listed  previously  in  the 
display  of  the  network. 

A. 3. 4.  Classification  and  scope 

The  ability  to  access  relevant  information  in  a standard  depends  on  the 
clarity  and  completeness  of  the  classification  scheme  used  to  organize  the 
standard.  The  basic  elements  of  the  classification  scheme  are  the  classi- 
fiers , which  denote  the  entities  and  attributes  pertinent  to  the  data  items 
in  the  standard.  Section  4.1  of  this  report  treats  classification  in 
detail.  Classifiers  appropriate  for  accessing  information  in  the  standard 
for  concrete  quality  are  listed  in  figure  A.  6.  The  notation  used  includes 
(see  Chapter  4 of  this  report) : 

REFE:  classifier  reference  number. 

NAME:  a character  string  used  to  identify  the  classifier. 

TYPE:  ACT(ive)  denotes  that  the  classifier  will  be  displayed  in  an 

Outline;  no  entry  indicates  that  the  classifier  will  not  be 
displayed. 

PARE:  specifies  the  reference  number  of  the  single  classifier  which 

is  the  parent  of  the  current  classifier  in  the  facet  (see 
Chapter  4 of  this  report) . 

TITL:  text  string  providing  the  full  classifier  name. 

FOSTER:  specifies  the  reference  numbers  of  multiple  parents  in 

different  fields  (see  Chapter  4 of  this  report) . 

COMMENT:  additional  explanatory  notes. 

The  scope  of  the  standard  is  established  once  pertinent  classifiers  have 
been  assigned  as  arguments  to  all  the  data  items.  The  scope  is  this  set  of 
pertinent  classifiers.  The  SASE-generated  scopelist  for  the  standard  for 
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concrete  quality  is  given  in  figure  A. 7.  The  scopelist  is  displayed  in  the 
numerical  order  of  the  classifiers.  Another  convenient  way  to  illustrate 
the  scope  of  the  chapter  is  by  means  of  an  index,  which  is  displayed  in  the 
alphabetical  order  of  the  classifiers.  The  SASE-generated  index  for  the 
standard  for  concrete  quality  is  given  in  figure  A.  8.  In  both  the  scope- 
list  and  index,  the  data  items  associated  with  any  single  classifier  are 
listed  in  datum  reference  number  sequence. 

A.  3. 5 Organization 

This  study  of  the  standard  for  concrete  quality  sought  not  only  to  analyze 
the  text  of  the  standard  in  terms  of  its  technical  content  but  also  to 
illustrate  the  utility  of  SASE  in  manipulating  the  organization  of  the  text 
without  modifying  the  technical  contents.  As  described  in  Chapter  4 of 
this  report,  SASE  enables  the  user  to  organize  trees  of  classifiers  that 
will  produce  the  desired  information  structure  (which  may  vary  depending  on 
the  user's  view  and  requirements  of  this  information).  Once  the  user  has 
established  a structured  organization  of  classifiers,  SASE  can  generate  a 
full  outline.  The  outline  expresses  the  organization,  and  also  displays 
the  data  items  associated  with  the  various  classifiers.  A SASE-generated 
outline  for  the  standard  for  concrete  quality  is  shown  in  figure  A.  9. 
Comparison  of  this  outline  with  the  text  in  figure  A.l  will  show  that  their 
arrangements  differ.  The  outline  shown  here  is  based  on  a revised  organi- 
zation for  the  standard  suggested  by  the  analysis  of  its  technical  con- 
tents . 

A. 4 Enhanced  understanding  of  a standard  through  SASE-based  analysis 

During  this  study  the  analysts  consulted  subject  matter  experts  to  ascer- 
tain that  the  technical  content  of  the  standard  was  interpreted  properly, 
and  to  check  the  correctness  and  usefulness  of  the  SASE-based  analysis. 
Chief  among  the  experts  consulted  was  the  chairman  of  the  ACI  committee 
responsible  for  Chapter  4 "Concrete  Quality"  of  the  ACI  318  standard. 
Several  questions  and  recommendations  for  clarifying  aspects  of  this  chap- 
ter, following  from  the  SASE-based  analysis,  were  revealed  in  the  consulta- 
tions. In  particular: 

1.  Section  4.1.1  says  that  the  overall  scope  of  Chapter  4 is  to 
minimize  the  frequency  of  strength  tests  falling  below  f'c.  How- 
ever, this  objective  is  not  a requirement  of  any  provision  of  the 
chapter.  A more  accurate  statement  of  the  chapter's  scope  may  be: 
to  realize  the  intentions  of  the  designer,  i.e.,  to  achieve  the 
specified  f'c  in  the  structure. 

2.  Chapter  4 does  not  provide  for  the  proportions  of  the  entire  mix, 
and  only  stipulates  requirements  for  water-cement  ratio. 

3.  A clause  within  section  4.4.3  concerning  the  required  average  test 
strength  of  concrete  from  a facility  without  an  adequate  record  is 
simply  a restatement  of  a clause  appearing  within  section  4.3.1. 
The  clause  seems  irrelevant  to  the  remainder  of  section  4.4.3,  and 
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in  this  instance,  the  redundancy  may  be  a source  of  confusion  for 
the  user  of  the  standard. 

4.  Having  defined  required  average  test  strength  of  concrete,  Chapter 
4 never  requires  its  use. 

5.  Section  4.5.1  specifies  that  where  suitable  data  from  field  tests 
or  laboratory  trial  batches  are  not  available,  permission  to  base 
concrete  proportions  on  water-cement  -ratio  limits  may  be  granted. 
However,  the  provision  does  not  specify  who  may  grant  such  per- 
mission. Two  possible  choices  are  the  project  engineer  and  the 
building  official. 

6.  The  clarity  of  Chapter  4 would  be  enhanced  through  the  use  of  a 
symbolic  representation  for  required  average  compressive  strength, 
namely  f'cr,  which  is  used  only  in  the  accompanying  commentary. 

7.  Chapter  4 should  provide  an  explicit  method  for  computing  f'cr 
used  as  a basis  for  selecting  concrete  proportions.  Equations  4-1 
and  4-2  in  the  accompanying  commentary  provide  such  a method. 

8.  Chapter  4 lacks  a definition  of  sufficiency  of  data  required  to 
justify  reducing  target  compressive  strength. 

The  reader  is  invited  to  study  Chapter  4 "Concrete  Quality"  of  the  1983 
edition  [2]  of  the  ACI  318  standard  and  compare  it  with  the  results  of  this 
study  to  see  how  some  of  the  above  questions  and  recommendations  have  been 
addressed. 
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PART 3 -CONSTRUCTION  REQUIREMENTS 


CHAPTER  4 - CONCRETE  QUALITY 


4.0  • Notation 

s specified  compressive  strength  of  con- 
crete, psi 

s average  splitting  tensile  strength  of 
lightweight  aggregate  concrete,  psi 

4.1  - General 


4.1.1  > Concrete  shall  be  proportioned  and 
produced  to  provide  an  average  compressive 
strength  sufficiently  high  to  minimize  frequency 
of  strength  tests  below  the  value  of  the  specified 
compressive  strength  of  concrete,  See  Sec- 
tions 4.3.1  and  4.8.2.3. 
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4.1.2  - Requirements  for  f;  shall  be  based  on  tests 
of  cylinders  made  and  tested  as  prescribed  in 
Section  4.8. 

4.1.3  - Unless  otherwise  specified,  f;  shall  be 
based  on  28-day  tests.  For  high-early-strength 
concrete,  the  test  age  for  f;  shall  be  as  indicated 
In  the  design  drawings  or  specifications. 

4.1.4  - Design  drawings  submitted  for  approval  or 
used  for  any  project  shall  show  the  specified 
compressive  strength  of  concrete  f;  for  which 
each  part  of  the  structure  is  designed. 

4.1.5 -Where  design  criteria  in  Sections  9.S.2.3, 

11.2  and  12.2.3(c)  provide  for  use  of  a splitting 
tensile  strength  value  of  concrete,  laboratory 
tests  shall  be  made  in  accordance  with 
“Specifications  for  Lightweight  Aggregates  for 
Structural  Concrete"  (ASTM  C 330)  to  establish 
value  of  fc  corresponding  to  specified  value  of 

4.1.6  - Splitting  tensile  strength  tests  Shan  not  be 
used  as  a basis  for  field  acceptance  of  concrete. 

4.2  - Selection  of  concrete  proportions 

4.2.1  - Proportions  of  materials  for  concrete  shall 
be  established  to  provide; 

(a)  Adequate  workability  and  proper  con- 
sistency to  permit  concrete  to  be  worked 
readily  into  the  forms  and  around  reinforcement 
under  conditions  of  placement  to  be  employed, 
without  excessive  segregation  or  bleeding 

(b)  Resistance  to  freezing  and  thawing  and 
other  aggressive  actions,  as  required  by  Sec- 
tion 4.6 


(c)  Conformance  with  strength  test 
requirements  of  Section  4.8 

4.2.2  - Where  different  materials  are  to  be  used  for 
different  portions  of  the  work,  each  combination 
shall  be  evaluated  separately. 

4.2.3  - Concrete  proportions,  including  water- 
cement  ratio,  shall  be  established  on  the  basis  of 
field  experience  (Section  4.3)  or  laboratory  trial 
batches  (Section  4.4)  with  materials  to  be  em- 
ployed, except  as  permitted  in  Section  4.5  or 
required  by  Section  4.6. 


4.3  - Proportioning  on  the  basis  of  field 
experience 

4.3.1  - Where  a concrete  production  facility  has  a 
record,  based  on  at  least  30  consecutive  strength 
tests  that  represent  similar  materials  and  con- 
ditions to  those  expected,  required  average 
compressive  strength  used  as  the  basis  for 
selecting  concrete  proportions  shall  exceed 
required  at  designated  test  age  by  at  least 

400  psi  if  standard  deviation  Is  les?  than  300  psi 
550  psi  if  standard  deviation  is  3(X)  to  4(X)  psi 
700  psi  if  standard  deviation  is  400  to  500  psi 
900  psi  If  standard  deviation  is  5(X)  to  6(X}  psi 

If  standard  deviation  exceeds  600  psi,  concrete 
proportions  shall  be  selected  to  produce  an 
average  strength  at  least  1200  psi  greater  than 
required  ___ 

4.3.2  - Strength  test  data  for  determining  standard 
deviation  shall  be  considered  to  comply  with 
Section  4.3.1  if  data  represents  either  a group  of  at 
least  30  consecutive  tests  or  a statistical  average 
for  two  groups  totaling  30  or  more  tests. 

4.3.3  - Strength  tests  used  to  establish  standard 
deviation  shall  represent  concrete  produced  to 
meet  a specified  strength  or  strengths  within  1000 
psi  of  that  specified  for  the  proposed  work. 

4.3.4  - Changes  In  materials  and  proportions 

within  the  population  of  background  tests  used  to 
establish  standard  deviation  shall  not  have  been 
more  closely  restricted  than  for  the  proposed 
work.  
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Figure  A.l  Text  of  a standard  for  concrete  quality  [1]  with  datum 
reference  numbers  annotated  in  the  margins. 
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TABLE  4.5  — MAXIMUM  PERMISSIBLE  WATER-CEMENT  RATIOS  FOR  CONCRETE  WHEN  STRENGTH 
DATA  FROM  TRIAL  BATCHES  OR  FIELD  EXPERIENCE  ARE  NOT  AVAILABLE 
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4.4  ■>  Proportioning  by  laboratory  trial 
batches 


4.4.1  - When  laboratory  trial  batches  are  used  as 
the  basis  for  selecting  concrete  proportions, 
strength  tests  shall  be  made  in  accordance  with 
"Method  of  Test  for  Compressive  Strength  of 
Cylindrical  Concrete  Specimens"  (ASTM  C 39)  on 
cylinders  prepared  in  accordance  with  "Method  of 
Making  and  Curing  Test  Specimens  in  the 
Laboratory”  (ASTM  C 192). 

4.4.2  - When  laboratory  trial  batches  are  made,  air 
content  shall  be  within  ±0.5  percent  and  slump 

182  within  ±0.75  in.  of  maximums  permitted  by  the 
specifications. 

4.4.3 -A  curve  shall  be  established  showing 
relationship  between  water-cement  ratio  (or 
cement  content)  and  compressive  strength.  Curve 
shall  be  based  on  at  least  three  points 
representing  batches  which  produce  strengths 
above  and  below  required  average  compressive 
strength  specified  in  Section  4.3.1.  If  concrete 
construction  facility  does  not  have  a record  based 
on  30  consecutive  strength  tests  representing 
simitar  materials  and  conditions  to  those  ex- 
pected, required  average  compressive  strength 
shall  be  1200  psi  greater  than  f;.  Each  point  shall 
represent  the  average  of  at  least  three  cylinders 
tested  at  28  days  or  the  specified  earlier  age. 

4.4.4  - Maximum  permissible  water<ement  ratio 
(or  minimum  cement  content)  for  concrete  to  be 

181  used  in  the  structure  shall  be  that  shown  by  the 
curve  to  produce  the  average  strength  indicated  in 
Section  4.3.1  or  4.4.3  unless  a lower  water-cement 
ratio  or  higher  strength  is  required  by  Section  4.6. 
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4.5  - Proportioning  by  water-cement  ratio 

4.5.1  - If  suitable  data  from  a record  of  30  con- 
secutive tests  (Section  4.3)  or  from  laboratory  trial 


batches  (Section  4.4)  are  not  available,  permission 
may  be  granted  to  base  concrete  proportions  on 
watercement  ratio  limits  in  Table  4.5. 

4.5.2  - Table  4.5  shall  be  used  only  for  concrete  to 
be  made  with  cements  meeting  strength 
requirements  for  Types  I,  lA,  !l,  IIA,  III,  IIIA,  or  V of 
“Specification  for  Portland  Cement"  (ASTM 
C 150),  or  Types  IS,  IS-A,  IS(MS).  IS-A(MS),  IP,  IP-A, 
or  P of  "Specification  for  Blended  Hydraulic 
Cements,"  (ASTM  C 595),  and  shall  not  be  applied 
to  concrete  containing  lightweight  aggregates  or 
admixtures  other  than  those  for  entraining  air. 

4.5.3  - Concrete  proportioned  by  water-cement 
ratio  limits  prescribed  in  Table  4.5  shall  also 
conform  to  special  exposure  requirements  of 
Section  4.6  and  to  compressive  strength  test 
criteria  of  Section  4.8. 


4.6  - Special  exposure  requirements 


4.6.1  - Concrete  that,  after  curing,  will  be  exposed  I 
to  freezing  temperatures  while  wet  shall  contain 
entrained  air  within  limits  of  Table  4.6.1,  and  in  I 
addition:  ■ i.i.l 


4.8.1.1- For  concrete  made  with  normal  weight 

aggregate,  water-cement  ratio  shall  not  exceed 
0.53  by  weight.  

4.6.1.2- For  concrete  made  with  lightweight 

aggregate,  specified  compressive  strength  f; 
shall  be  at  least  3000  psi.  
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TABLE  4.6.1  — CONCRETE  AIR  CONTENT  FOR 
VARIOUS  SIZES  OF  COARSE  AGGREGATE 


Nominal  maximum 
aizeof  coarae 
aggregate.  In. 

Total  air  content, 
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Figure  A.l  Text,  continued 
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4.6.2  - Concrete  that  is  intended  to  be  watertight 
shall  conform  to  the  following: 

4.6.2.1  - For  concrete  made  with  normal  weight 
aggregate,  water-cement  ratio  shall  not  exceed 
0.50  by  weight  for  exposure  to  fresh  water  and 
0.45  by  weight  for  exposure  to  seawater. 

4.6.2.2  - For  concrete  made  with  lightweight 
aggregate,  specified  compressive  strength  f; 
shall  be  at  least  3750  psi  for  exposure  to  fresh 
water  and  4000  psi  for  exposure  to  seawater. 

4.6.d  - Concrete  that  will  be  exposed  to  injurious 
concentrations  of  sulfate-containing  solutions 
shall  be  made  with  sulfate-resisting  cement,  and 
In  addition: 

4.6.3.1  - For  concrete  made  with  normal  weight 
aggregate,  water-cement  ratio  shall  not  exceed 
0.50  by  weight. 

4.6.3J2  - For  concrete  made  with  lightweight 
aggregate,  specified  compressive  strength 
shall  be  at  least  3750  psi. 

4.7  - Average  strength  reduction 

After  sufficient  test  data  become  available  from 
the  job,  methods  of  "Recommended  Practice  for 
Evaluation  of  Compression  Test  Results  of 
Concrete  (ACI  214-65)"  may  be  used  to  reduce  the 
amount  by  which  the  average  strength  must  ex- 
ceed fc  below  that  indicated  in  Section  4.3.1 
provided: 

(a)  Probable  frequency  of  strength  tests  more 
than  500  psi  below  f.  will  not  exceed  1 in  100, 

(b)  Probable  frequency  of  an  average  of  three 
consecutive  strength  tests  below  f;  will  not 
exceed  1 in  100,  and 

(c)  Special  exposure  requirements  of  Section 
4.6  are  met. 


4.8  - Evaluation  and  acceptance  of 
concrete 

4.8.1  - Frequency  of  testing 

4.8.1.1  - Samples  for  strength  tests  of  each  class 
of  concrete  placed  each  day  shall  be  taken  not 
less  than  once  a day,  nor  less  than  once  for  each 
ISO  cu  yd  of  concrete,  nor  less  than  once  for  each 
5000  sq  ft  of  surface  area  for  slabs  or  walls. 

4J.1.2~On  a given  project,  If  total  volume  of 
concrete  1s  such  that  frequency  of  testing 
required  by  Section  4.B.1.1  would  provide  less 
than  five  strength  tests  for  a given  class  of  con- 
crete, tests  shall  be  made  from  at  least  five  ran- 
domly selected  batches  or  from  each  batch  If 
fewer  than  five  batches  are  used. 


4.8.1.3-When  total  quantity  of  a given  class  of 
concrete  is  less  than  50  cu  yd,  strength  tests  may 
be  waived  by  the  Building  Official,  If  in  his 
judgment  adequate  evidence  of  satisfactory 
strength  is  provided. 

4.B.1.4- Average  strength  of  two  cylinders  from 
the  same  sample,  tested  at  28  days  or  the 
specified  earlier  age,  is  required  for  each  strength 
test. 


4.8.2  - Tests  of  laboratory-cured  specimens 

4.8.2.1  - Samples  for  strength  tests  shall  be  taken 
in  accordance  with  “Method  of  Sampling  Fresh 
Concrete"  (ASTM  C 172). 

4.8.2.2- Cylinders  for  strength  tests  shall  be 
molded  and  laboratory-cured  in  accordance  with 
“Method  of  Making  and  Curing  Concrete  Test 
Specimens  in  the  Field"  (ASTM  C 31)  and  tested  In 
accordance  with  “Method  of  Test  for  Com- 
pressive Strength  of  Cylindrical  Concrete 
Specimens"  (ASTM  C 39).  
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4.B.2.3- Strength  level  of  an  individual  class  of 
concrete  shall  be  considered  satisfactory  if  both 
of  the  following  requirements  are  met: 

(a)  The  average  of  all  sets  of  three  consecutive 
strength  tests  equal  or  exceed  required 

(b)  No  individual  strength  test  (average  of  two 

cylinders)  falls  below  required  by  more  than 
500  psi.  

4.5.2.4  - If  either  of  the  requirements  of  Section 
4.B.2.3  are  not  met,  steps  shall  be  taken  Im- 
mediately to  increase  the  average  of  subsequent 
strength  test  results.  Additionally,  requirements 
of  Section  4.8.4  shall  be  observed  If  the 
requirement  of  Section  4.8.2.3(b)  is  not  met.  _____ 

4.8.3 — Tests  of  field-cured  specimens 

4. 8. 3.1  -The  Building  Official  may  require 
strength  tests  of  cylinders  cured  under  field 
conditions  to  check  adequacy  of  curing  and 
protection  of  concrete  In  the  structure. 

4.8.3.2  - Field-cured  cylinders  shall  be  cured 
under  field  conditions  in  accordance  with  Section 

7.4  of  “Method  of  Making  and  Curing  Concrete 
Test  Specimens  in  the  Field"  (ASTM  C 31). 


370 


380 


420 


4.B.3.3  - Field-cured  test  cylinders  shall  be 
molded  at  the  same  time  and  from  the  same 
aamples  as  laboratory-cured  test  cylinders. 

4.B.3.4  - Procedures  for  protecting  and  curing 
concrete  shall  be  improved  when  strength  of  field- 
cured  cylinders  at  the  test  age  designated  for 
measuring  f;  Is  less  than  85  percent  of  that  of 
companion  laboratory-cured  cylinders.  When 


Figure  A.l  Text,  continued. 
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400 


laboratory-cured  cylinder  strengths  are  ap- 
preciably higher  than  ti,  field-cured  cylinder 
strengths  need  not  esceed  by  more  than  500  psi 
even  though  the  65  percent  criterion  is  not  met. 

4.8.4  - Investigation  of  low-strength  test  results 

4.8.4.1-lf  any  strength  test  (Section  4.8.1.4)  of 
laboratory-cured  cylinders  falls  below  required  ti 
by  more  than  5(X)  psi  [Section  4.8.2.3(b)]  or  If  tests 
of  field-cured  cylinders  indicate  deficiencies  In 
protection  and  curing,  steps  shall  be  taken  to 
assure  that  load-carrying  capacity  of  the  structure 
is  not  jeopardized. 

4.S.4.2  - If  the  likelihood  of  low-strength  concrete 
is  confirmed  and  computations  indicate  that  ioad- 
carrying  capacity  may  have  been  significantly 
reduced,  tests  of  cores  drilled  from  the  area  In 
question  may  be  required  in  accordance  with 
“Method  of  Obtaining  and  Testing  Drilled  Cores 
and  Sawed  Beams  of  Concrete"  (ASTM  C 42).  In 
such  case,  three  cores  shall  be  taken  for  each 
strength  test  more  than  500  psi  below  required  ti. 


4.8.4.3-lf  concrete  in  the  structure  will  be  dry 
under  service  conditions,  cores  shall  be  air  dried 
(temperature  60  to  80  F,  relative  humidity  less 
than  60  percent)  for  7 days  before  test  and  shall  be 
tested  dry.  If  concrete  in  the  structure  will  be 
more  than  superficially  wet  under  service  con- 
ditions, cores  shall  be  immersed  in  water  for  at 
least  48  hr  and  be  tested  wet. 

4.8.4.4  - Concrete  in  an  area  represented  by  core 
tests  shall  be  considered  structurally  adequate  if 
the  average  of  three  cores  is  equal  to  at  least  85 
percent  of  ti  and  if  no  single  core  is  less  than  75 
percent  of  f;.  To  check  testing  accuracy,  locations 
represented  by  erratic  core  strengths  may  be 
retested. 


4.8.4.S  - If  criteria  of  Section  4.8.4.4  are  not  met, 
and  if  structural  adequacy  remains  in  doubt,  the 
responsible  authority  may  order  load  tests  as 
outlined  in  Chapter  20  for  the  questionable  por- 
tion of  the  structure,  or  take  other  action  ap- 
propriate to  the  circumstances. 


Figure  A.l  Text,  concluded. 
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REFE  NAME  SECT  PAGE  VALU  SOUR 

1 RSTA  S413  13  BOOL  DERI 

TITLE  : STRNTH  TESTS  SHALL  BE  CONDUCTED 
INGREDIENTS : 1000  1010 
ARGUMENT:  14  65 

EQUIVALENTS  : 

COMMENT : 

TYPE  STAT  UTIL 

TABL  CLAS  REQU 

AT  SPECIFIED  AGE 

REFE  NAME 

SECT 

PAGE 

VALU 

SOUR 

TYPE 

STAT 

UTIL 

10  SCSD 

S414 

13 

BOOL 

DERI 

CLAS 

REQU 

TITLE  : REQ 

FOR  SPEC 

OF  CONCRETE 

STRNTH 

ON  DES 

DRAWING 

INGREDIENTS: 

1500 

ARGUMENT : 

59  74 

EQUIVALENTS 

COMMENT : 

REFE  NAME 

SECT 

PAGE 

VALU 

SOUR 

TYPE 

STAT 

UTIL 

20  FCT 

S415 

13 

BOOL 

DERI 

TABL 

CLAS 

REQU 

TITLE  : REQ 

EST  VAL 

OF  F(CT) 

CORRES  TO  SPEC  VAL 

OF  F'C 

INGREDIENTS 

1020  1030 

ARGUMENT : 

15  74 

EQUIVALENTS 

COMMENT : 

REFE  NAME 

SECT 

PAGE 

VALU 

SOUR 

TYPE 

STAT 

UTIL 

30  STS 

S416 

13 

BOOL 

DERI 

CLAS 

REQU 

TITLE  : REQ 

NOT  ACC 

CONC  ON 

BASIS 

OF  SPLIT  TENSILE  STRNTH 

INGREDIENTS 

1510 

ARGUMENT : 

15  74 

EQUIVALENTS 

COMMENT : 

REFE  NAME 

SECT 

PAGE 

VALU 

SOUR 

TYPE 

STAT 

UTIL 

40  WCC 

S421 

13 

BOOL 

DERI 

CLAS 

REQU 

TITLE  : REQ 

TO  PROP 

FOR  ADEQ  WORKABILITY  & CONSISTENCY 

INGREDIENTS 

1520 

ARGUMENT : 

09  06 

EQUIVALENTS 

COMMENT : 

REFE  NAME 

SECT 

PAGE 

VALU 

SOUR 

TYPE 

STAT 

UTIL 

60  DATS 

S431 

13 

NUME 

DERI 

TABL 

CLAS 

DETE 

TITLE  : DET 

OF  REQUIRED  AVG 

TEST 

STRNTH 

BY  FIELD  EXP 

INGREDIENTS 

1040  70 

ARGUMENT : 

04  06 

EQUIVALENTS 

: 

COMMENT : 

Figure  A. 2 SASE-generated  listing  of  derived  data  items  for 
a standard  for  concrete  quality. 
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REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 
70  ARG4  S432  13  NUME  DERI  TABL  CLAS  DETE 

TITLE  : DET  OF  STD  DEV  OF  STRENGTH  TEST  DATA 
INGREDIENTS: 1050  1290  1300 
ARGUMENT:  04  06 

EQUIVALENTS  : 

COMMENT : 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

181  S444  BOOL  DERI  CLAS  REQU 

TITLE  : REQ  THAT  LTB  W/C  RAT  YIELDS  AVG  TEST  STR  IN  60 
INGREDIENTS: 182  60 

ARGUMENT:  06  63 

EQUIVALENTS  : 

COMMENT:  REQUIREMENT  THAT  LTB  WATER-CEMENT  RATIO  YIELDS  AVG  T 
EST  STIPULATED  IN  DATUM  60 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

182  S444  NUME  DERI  TABL  CLAS  DETE 

TITLE  : DET  OF  STR  CORR  TO  W/C  RATIO  OF  LTB 
INGREDIENTS: 1060  1070  1080  1090  60 
ARGUMENT:  06  63 

EQUIVALENTS  : 

COMMENT:  DETERMINATION  OF  STRENGTH  CORRESPONDING  TO  WATER- CEM 
ENT  RATIO  OF  LAB -TRIAL  BATCH 

REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

200  CEMT  S461  14  BOOL  DERI  TABL  CLAS  REQU 

TITLE  : REQ  FOR  MAX  PERMISSIBLE  W/C  RATIO  BY  TABLE  4.5 
INGREDIENTS : 1100  1110  1120  1130 
ARGUMENT:  06  63 

EQUIVALENTS  : 

COMMENT : 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

230  ENAC  S461  14  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  EXPOSED  TO  FREEZ  AIR  CONT  PER  TBL  4.6.1 
INGREDIENTS: 1530  1540 
ARGUMENT:  11  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  EXPOSED  TO  FREEZING  WHEN  WET  SHALL  HAVE  AN 
AIR  CONTENT  IN  ACCORD  WITH  TABLE  4.6.1. 


Figure  A. 2 SASE-generated  listing  of  derived  data  items,  continued. 
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REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

240  CEFT  S461  14  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  EXP  TO  FREEZ-MADE  OF  LT  WT  AGG-F' C>=3000PSI 
INGREDIENTS: 1120  1530  1550 
ARGUMENT:  11  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  EXPOSED  TO  FREEZING  WHEN  WET  & MADE  OF  LIGH 
T WEIGHT  AGGREGATE  SHALL  HAVE  F' C <=  3000  PSI 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

250  RCEF  S461  14  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  EXP  FREEZ-NORM  WT  AGG-W/C  RATIO  >0.83 
INGREDIENTS: 1530  1120  1560 
ARGUMENT:  11  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  EXPOSED  TO  FREEZING  WHEN  WET  AND  MADE  OF  NO 
RMAL  WEIGHT  AGGREGATE  SHALL  HAVE  A W/C  RATIO  NOT  EXCE 
EDING  .83 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

260  FRWA  S462  15  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  NORM  WT  AGG  EXPOSED  FRESH  H20-W/C  RATIO<0 . 5 
INGREDIENTS : 1120  1570  1580  1560 
ARGUMENT:  13  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  OF  NORMAL  WEIGHT  AGGREGATE  EXPOSED  TO  FRESH 
WATER  AND  INTENDED  TO  BE  WATER  TIGHT  SHALL  HAVE  A W/C 
RATIO  < .5 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

261  SEWA  S462  15  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  NORM  WT  AGG  EXPOSED  SEA  H20-W/C  RATIO<=0.45 
INGREDIENTS : 1120  1570  1580  1560 
ARGUMENT:  13  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  OF  NORMAL  WEIGHT  AGGREGATE  EXPOSED  TO  SEA  W 
ATER  AND  INTENDED  TO  BE  WATERTIGHT  SHALL  HAVE  A W/C  R 
ATIO  <=  .45 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

270  WTCF  S462  15  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  LT  WT  AGG  EXPOSED  FRESH  H20-F'C  >=  3750PSI 
INGREDIENTS: 1120  1550  1570  1580 
ARGUMENT:  13  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  OF  LIGHT  WEIGHT  AGGREGATE  EXPOSED  TO  FRESH 
WATER  INTENDED  TO  BE  WATERTIGHT  SHALL  HAVE  F'C  >=  37 
50  PSI 


Figure  A. 2 SASE-generated  listing  of  derived  data  items,  continued. 
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REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

271  WTCS  S462  15  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  LT  WT  AGG  EXPOSED  SEA  H20-F'C  >=4000  PSI 
INGREDIENTS : 1120  1550  1570  1580 
ARGUMENT:  13  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  OF  LIGHT  WEIGHT  AGGREGATE  EXPOSED  TO  SEA  WA 
TER  AND  INTENDED  TO  BE  WATERTIGHT  SHALL  HAVE  F'C  >=  4 
000  PSI 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

280  SERI  S463  15  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  NORM  WT  AGG  EXPOS  TO  SULFATE-W/C  RATI0<=0 . 5 
INGREDIENTS: 1590  1120  1560 

ARGUMENT:  39  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  MADE  OF  NORMAL  WEIGHT  AGGREGATE  AND  EXPOSED 
TO  SULFATE  SHALL  HAVE  A W/C  RATIO  <=  .5 

REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

281  SER2  S463  15  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  LT  WT  AGG  EXPOSED  TO  SULFATE-F'C  >=3750  PSI 
INGREDIENTS : 1120  1550  1590 

ARGUMENT:  39  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  MADE  OF  LIGHT  WEIGHT  AGGREGATE  AND  EXPOSED 
TO  SULFATE  SHALL  HAVE  F’C  >=■  3750  PSI 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

282  SER3  S463  15  BOOL  DERI  CLAS  REQU 

TITLE  : CONC  EXPOSED  INJ  SULFATE  MADE  W.  SULFATE-RES  CEM 
INGREDIENTS: 1590  1110 
ARGUMENT:  39  70 

EQUIVALENTS  : 

COMMENT:  CONCRETE  EXPOSED  TO  INJURIOUS  CONCENTRATIONS  OF  SULF 
ATE  CONTAINING  SOLUTIONS  SHALL  BE  MADE  WITH  SULFATE -R 
ISTING  CEMENT 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

290  AASR  S47  15  BOOL  DERI  TABL  CLAS  REQU 

TITLE  : REQ  FOR  PERMIS  REDUCTN  IN  REQ'D  AVG  TEST  STRNGTH 
INGREDIENTS: 1140  1150  1160  1250  1251 
ARGUMENT:  04  06 

EQUIVALENTS  : 

COMMENT : 


Figure  A. 2 SASE-generated  listing  of  derived  data  items,  continued. 


134 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE 

300  STS  S481  15  BOOL  DERI  TABL 

TITLE  : SAMPLE  STR  TESTS  FOR  EACH  CIASS  OF  CONC 
INGREDIENTS : 1170  1180  1190  1200  1210 
ARGUMENT:  42  65  41 

EQUIVALENTS  : 

COMMENT:  ENCOMPASSES  SECTIONS  4. 8. 1.1  THROUGH  4 

STAT  UTIL 
CLAS  REQU 

REQ  FREQ 

8.1.4 

REFE  NAME  SECT 

PAGE 

VALU 

SOUR 

TYPE 

STAT 

UTIL 

330  SLCS  S482 

15 

BOOL 

DERI 

ClAS 

REQU 

TITLE  : SAMPLES  FOR 

STR  TESTS  TAKEN  IN  ACCORD  ASTM  C172 

INGREDIENTS : 1600 

ARGUMENT:  43  41 

65 

EQUIVALENTS  : 

COMMENT : 

REFE  NAME  SECT 

PAGE 

VALU 

SOUR 

TYPE 

STAT 

UTIL 

340  MSTS  S482 

15 

BOOL 

DERI 

CLAS 

REQU 

TITLE  : CYL  MOLDED  & 

LAB  CURED  IN 

ACCORD 

WITH  ASTM  C31 

INGREDIENTS: 1610 

ARGUMENT:  07  41 

65 

EQUIVALENTS  : 

COMMENT:  CYLINDERS  FOR  STRENGTH  TESTS  OF 

LABORATORY  CURED  SPE 

CIMENS  SHALL 

BE  MOLDED  AND  LAB  CURED  IN 

ACCORD 

WITH  A 

STM  C31 

REFE  NAME  SECT 

PAGE 

VALU 

SOUR 

TYPE 

STAT 

UTIL 

350  CCST  S482 

15 

BOOL 

DERI 

CLAS 

REQU 

TITLE  : CYL  STR  TEST 

LAB  CURED  SPEC  TESTED  PER  ASTM  C39 

INGREDIENTS: 1090 

ARGUMENT:  55  65 

EQUIVALENTS  : 

COMMENT:  CYLINDERS  FOR  STRENGTH  TESTS  OF 

LABORATORY  CURED  SPE 

CIMENS  SHALL 

BE  TESTED  IN 

ACCORD 

WITH  ASTM  C39 

REFE  NAME  SECT 

PAGE 

VALU 

SOUR 

TYPE 

STAT 

UTIL 

370  ASL  S482 

15 

BOOL 

DERI 

TABL 

CLAS 

REQU 

TITLE  : ACCEPT  OF  STR  LEVELS  BASED  ON  LAB -CURED 

CYL 

INGREDIENTS : 1140  1220  1250 

1251  1550 

ARGUMENT:  55  65 

EQUIVALENTS  : 

COMMENT:  PERTAINS  ALSO  TO  SECTION 

4. 8. 3. 4 

Figure  A. 2 SASE-generated  listing  of  derived  data  items,  continued. 
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REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

380  RAl  S482  15  BOOL  DERI  CLAS  REQU 

TITLE  : SOMEONE  SHALL  TAKE  STEPS  TO  INCREASE  STR  OF  CONC 
INGREDIENTS: 370 
ARGUMENT:  48  65 

EQUIVALENTS  : 

COMMENT : 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

381  RA2  S484  15  BOOL  DERI  CLAS  REQU 

TITLE  : SOMEONE  SHALL  TAKE  STEPS -LD  CAP  NOT  JEOPARDIZED 
INGREDIENTS: 370  420 

ARGUMENT:  48  65 

EQUIVALENTS  : 

COMMENT:  SOMEONE  SHALL  TAKE  STEPS  TO  ASSURE  THAT  LOAD  CARRYIN 
G CAPACITY  IS  NOT  JEOPARDIZED  IF  4.8.2.3(B)  ISN'T  MET 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

400  SBCT  S484  15  BOOL  DERI  TABL  CLAS  REQU 

TITLE  : ACCEPT  OF  IN  SITU  STR  BASED  ON  CORE  TESTS 
INGREDIENTS: 1260  1270  1271  1280  1550 
ARGUMENT:  52  53  65 

EQUIVALENTS  : 

COMMENT:  FROM  SECTION  4. 8. 4, 2 THROUGH  4. 8. 4. 4 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

410  LT  S484  16  BOOL  DERI  CLAS  REQU 

TITLE  : DEC  BY  BLDG  OFFL  TO  ORDER  LD  TESTS  OR  OTHER  REQ 
INGREDIENTS: 400  1620 

ARGUMENT:  51  53  65 

EQUIVALENTS  : 

COMMENT:  IF  STRUCTURAL  ADEQUACY  REMAINS  IN  DOUBT,  DECISION  BY 
BUILDING  OFFICIAL  TO  ORDER  LOAD  TESTS  OR  TAKE  OTHER  A 
PPROPRIATE  ACTIONS  IS  REQUIRED. 


REFE  NAME  SECT  PAGE  VALU  SOUR  TYPE  STAT  UTIL 

420  PROC  S483  16  DERI  TABL  CLAS  REQU 

TITLE  : PROC  FOR  PROT  & CURING  CONC  SHALL  BE  ADEQUATE 
INGREDIENTS: 1230  1240  1250  1310  1550 
ARGUMENT:  51  53  65 

EQUIVALENTS  : 

COMMENT:  PROCEDURES  FOR  PROTECTING  AND  CURING  CONCRETE  IN  THE 
STRUCTURE  SHALL  BE  ADEQUATE 


Figure  A. 2 SASE- generated  listing  of  derived  data  items,  concluded. 
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REFE 

NAME 

SOUR 

TITL 

1000 

ICON 

INPU 

TYPE  OF  CONCRETE 

REFE 

NAME 

SOUR 

TITL 

1010 

AGE 

INPU 

TEST  AGE 

REFE 

NAME 

SOUR 

TITL 

1020 

FCT 

INPU 

VALUE  OF  F(CT) 

REFE 

NAME 

SOUR 

TITL 

1030 

LABT 

INPU 

LAB  TEST  CONDUCT 

REFE 

NAME 

SOUR 

TITL 

1040 

STDV 

INPU 

STD  DEVIATION  OF  STR  TEST  DATA 

REFE 

NAME 

SOUR 

TITL 

1050 

RDAT 

INPU 

REPRESENTIVENESS  OF  STRENGTH  TEST  DATA 

REFE 

NAME 

SOUR 

TITL 

1060 

LTBT 

INPU 

PREPARATION  OF  LTB  TEST  SPECIMENS 

REFE 

NAME 

SOUR 

TITL 

1070 

LTAI 

INPU 

LTB  AIR  CONTENT 

REFE 

NAME 

SOUR 

TITL 

1080 

LTSL 

INPU 

LTB  SLUMP 

REFE 

NAME 

SOUR 

TITL 

1090 

LTBT 

INPU 

LTB  TEST  PROCEDURE 

REFE 

NAME 

SOUR 

TITL 

1100 

PPWC 

INPU 

PERMISSION  TO  BASE  PROPORTIONS  ON  W/C  RATIO 

REFE 

NAME 

SOUR 

TITL 

1110 

TCEM 

INPU 

TYPE  OF  CEMENT 

REFE 

NAME 

SOUR 

TITL 

1120 

TAGG 

INPU 

TYPE  OF  AGGREGATE 

REFE 

NAME 

SOUR 

TITL 

1130 

TADM 

INPU 

TYPE  OF  ADMIXTURE 

REFE 

NAME 

SOUR 

TITL 

1140 

QDAT 

INPU 

QUALITY  OF  TEST  DATA  PER  ACI214-65 

Figure  A. 3 SASE- generated  listing  of  input  data  items  for 
a standard  for  concrete  quality. 
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REFE 

1150 

NAME 

PITS 

SOUR 

INPU 

TITL 

PROBABILITY  (STRENGTH  < F’C  - 500) 

REFE 

1160 

NAME 

P3TS 

SOUR 

INPU 

TITL 

PROBABILITY  (AVG  OF  3 STRENGTH  TESTS  < F'C) 

REFE 

1170 

NAME 

QUAN 

SOUR 

INPU 

TITL 

TOTAL  QUANTITY  OF  CONCRETE  PLACED 

REFE 

1180 

NAME 

APPR 

SOUR 

INPU 

TITL 

BUILDING  officials’  APPROVAL  OF  STRENGTH 

REFE 

1190 

NAME 

STSA 

SOUR 

INPU 

TITL 

STRENGTH  TEST  SAMPLING 

REFE 

1200 

NAME 

TSNU 

SOUR 

INPU 

TITL 

NUMBER  OF  TESTS  PER  CLASS  OF  CONCRETE 

REFE 

1210 

NAME 

BCHN 

SOUR 

INPU 

TITL 

NUMBER  OF  BATCHES  PER  CLASS  OF  CONCRETE 

REFE 

1220 

NAME 

LOTS 

SOUR 

INPU 

TITL 

NUMBER  OF  TESTS  < (F’C  - 500) 

REFE 

1230 

NAME 

RTFC 

SOUR 

INPU 

TITL 

REQ  FOR  STRENGTH  TEST  OF  FIELD  CURED  CYLINDE 

REFE 

1240 

NAME 

MCFC 

SOUR 

INPU 

TITL 

METHOD  OF  MOLDING  AND  CURING  FIELD  CURED  CYL 

REFE 

1250 

NAME 

TSLC 

SOUR 

INPU 

TITL 

TEST  STRENGTH  OF  LAB  CURED  CYLINDERS 

REFE 

1251 

NAME 

ACST 

SOUR 

INPU 

TITL 

AVG  OF  3 CONSECUTIVE  STR  TESTS  OF  LAB  CURED 

REFE 

1260 

NAME 

MOTC 

SOUR 

INPU 

TITL 

METHOD  OF  OBTAINING  AND  TESTING  CORES 

REFE 

1270 

NAME 

NUMC 

SOUR 

INPU 

TITL 

NUMBER  OF  CORES  PER  LOW  STRENGTH  TEST 

REFE 

1271 

NAME 

GTS 

SOUR 

INPU 

TITL 

CORE  TEST  STRENGTH 

REFE 

1280 

NAME 

CTSA 

SOUR 

INPU 

TITL 

3 CORE  TEST  STRENGTH  AVERAGE 

Figure  A. 3 SASE- generated  listing  of  input  data  items,  continued. 
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REFE 

NAME 

SOUR 

TITL 

1290 

PREV 

INPU 

PREVIOUSLY  SPECIFIED  F'C 

REFE 

NAME 

SOUR 

TITL 

1300 

BMP 

INPU 

BACKGROUND  MATERIALS  AND  PROPORTIONING 

REFE 

NAME 

SOUR 

TITL 

1310 

TSFC 

INPU 

TEST  STRENGTH  OF  FIELD -CURED  CYLINDERS 

REFE 

NAME 

SOUR 

TITL 

1500 

SPFC 

INPU 

SPECIFICATION  OF  F'C  ON  DESIGN  DRAWINGS 

REFE 

NAME 

SOUR 

TITL 

1510 

CFCT 

INPU 

CRITERIA  FOR  USE  OF  F(CT) 

REFE 

NAME 

SOUR 

TITL 

1520 

W&C 

INPU 

WORKABILITY  AND  CONSISTENCY 

REFE 

NAME 

SOUR 

TITL 

1530 

FRX 

INPU 

EXPOSURE  TO  FREEZING 

REFE 

NAME 

SOUR 

TITL 

1540 

AC 

INPU 

AIR  CONTENT 

REFE 

NAME 

SOUR 

TITL 

1550 

VFC 

INPU 

VALUE  OF  SPECIFIED  F'C 

REFE 

NAME 

SOUR 

TITL 

1560 

WCR 

INPU 

W/C  RATIO 

REFE 

NAME 

SOUR 

TITL 

1570 

TWX 

INPU 

TYPE  OF  WATER  EXPOSURE 

REFE 

NAME 

SOUR 

TITL 

1580 

INT 

INPU 

INTENTION  FOR  WATER  TIGHTNESS 

REFE 

NAME 

SOUR 

TITL 

1590 

SX 

INPU 

SULFATE  EXPOSURE 

REFE 

NAME 

SOUR 

TITL 

1600 

INPU 

METHOD  OF  SAMPLING  FRESH  CONCRETE 

REFE 

NAME 

SOUR 

TITL 

1610 

MMCC 

INPU 

METH  OF  MAKING  & CURING  CONC  TEST  SPEC  IN  FI 

REFE 

NAME 

SOUR 

TITL 

1620 

MLTS 

INPU 

METH  OF  LOAD  TESTING  THE  STRUCTURE  (CHAP  20) 

Figure  A. 3 SASE-generated  listing  of  input  data  items,  concluded. 
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COMPLETE  GLOBAL  INGREDIENCE  NETWORK 
EXTREME  LEVEL  FROM  OUTPUT 


0 12  3 4 

1 STRNTH  TESTS  SHALL  BE  CONDUCTED  AT  SPECIFIED  AGE 
: , _ 1000  TYPE  OF  CONCRETE 

: . . . 1010  TEST  AGE 

10  REQ  FOR  SPEC  OF  CONCRETE  STRNTH  ON  DES  DRAWING 
;...1500  SPECIFICATION  OF  F'C  ON  DESIGN  DRAWINGS 

20  REQ  EST  VAL  OF  F(CT)  CORRES  TO  SPEC  VAL  OF  F'C 
:...1020  VALUE  OF  F(CT) 

: . . . 1030  LAB  TEST  CONDUCT 

30  REQ  NOT  ACC  CONC  ON  BASIS  OF  SPLIT  TENSILE  STRTH 
: . . .1510  CRITERIA  FOR  USE  OF  F(CT) 

40  REQ  TO  PROP  FOR  ADEQ  WORKABILITY  & CONSISTENCY 
: . . .1520  WORKABILITY  AND  CONSISTENCY 


181  REQ  THAT  LTB  W/C  RAT  YIELDS  AVG  TEST  STR  IN  60 
. . . .182  DET  OF  STR  CORR  TO  W/C  RATIO  OF  LTB 
:...1060  PREPARATION  OF  LTB  TEST  SPECIMENS 
: ...  1070  LTB  AIR  CONTENT 
• : . . . 1080  LTB  SLUMP 

: ...  1090  LTB  TEST  PROCEDURE 

: 60  DET  OF  REQUIRED  AVG  TEST  STRNTH  BY  FIELD  EXP 

: . . . 1040  STD  DEVIATION  OF  STR  TEST  DATA 

: 70  DET  OF  STD  DEV  OF  STRENGTH  TEST  DATA 

:...1050  REPRESENTATIVENESS  OF  STRENGTH  TEST  DATA 
:...1290  PREVIOUSLY  SPECIFIED  F'C 
: . . . 1300  BACKGROUND  MATERIALS  AND  PROPORTIONING 
-60*  DET  OF  REQUIRED  AVG  TEST  STRNTH  BY  FIELD  EXP 


200 


REQ  FOR  MAX  PERMISSIBLE  W/C  RATIO  BY  TABLE  4.5 
1100  PERMISSION  TO  BASE  PROPORTIONS  ON  W/C  RATIO 
1110  TYPE  OF  CEMENT 
1120  TYPE  OF  AGGREGATE 
1130  TYPE  OF  ADMIXTURE 


Figure  A. 4 SASE-generated  global  ingredience  network 
for  a standard  for  concrete  quality.  (See  section  A. 3. 3 
for  a discussion  of  the  network  nomenclature  used  here.) 
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EXTREME  LEVEL  FROM  OUTPUT 
0 12  3 4 

230  CONG  EXPOSED  TO  FREEZING  AIR  CONT  PER  TBL  4.6.1 
:...1530  EXPOSURE  TO  FREEZING 
: . . . 1540  AIR  CONTENT 

240  CONG  EXP  TO  FREEZ-MADE  OF  LT  WT  AGG-F' 0-3000PSI 
:..-1120  TYPE  OF  AGGREGATE 
: . . -1530  EXPOSURE  TO  FREEZING 
: 1550  VALUE  OF  SPECIFIED  F'C 

250  CONG  EXP  FREEZ-NORM  WT  AGG-W/C  RATIO  >0.83 
: . . -1530  EXPOSURE  TO  FREEZING 
: . . -1120  TYPE  OF  AGGREGATE 
: . . . 1560  W/C  RATIO 

260  CONG  NORM  WT  AGG  EXPOSED  FRESH  H20-W/C  RATIO<0 . 5 
; . . -1120  TYPE  OF  AGGREGATE 

: . . .1570  TYPE  OF  WATER  EXPOSURE 
: . . .1580  INTENTION  FOR  WATER  TIGHTNESS 
:..-1560  W/C  RATIO 

261  CONG  NORM  WT  AGG  EXPOSED  SEA  H20-W/C  RATIO<0.45 
: . . -1120  TYPE  OF  AGGREGATE 

; . . -1570  TYPE  OF  WATER  EXPOSURE 
: . . -1580  INTENTION  FOR  WATER  TIGHTNESS 
:..-1560  W/C  RATIO 

270  CONG  LT  WT  AGG  EXPOSED  FRESH  H20-F'C  >-  3750PSI 
: . . -1120  TYPE  OF  AGGREGATE 

-1550  VALUS  OF  SPECIFIED  F'C 

: . .-1570  TYPE  OF  WATER  EXPOSURE 
:..-1580  INTENTION  FOR  WATER  TIGHTNESS 

271  CONG  LT  WT  AGG  EXPOSED  SEA  H20-F'C  > 4000  PSI 
: . . -1120  TYPE  OF  AGGREGATE 

; -1550  VALUE  OF  SPECIFIED  F'C 

: . . -1570  TYPE  OF  WATER  EXPOSURE 
:..-1580  INTENTION  FOR  WATER  TIGHTNESS 

280  CONG  NORM  WT  AGG  EXPOS  TO  SULFATE-W/C  RATI0<=0 . 5 
: ...  1590  SULFATE  EXPOSURE 
:..-1120  TYPE  OF  AGGREGATE 
: . . -1560  W/C  RATIO 


Figure  A. 4 SASE- generated  global  ingredience  network,  continued. 
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EXTREME  LEVEL  FROM  OUTPUT 
0 12  3 4 

281  CONG  LT  WT  AGG  EXPOSED  TO  SULFATE-F'C  > 3750  PSI 
:..-1120  TYPE  OF  AGGREGATE 

-1550  VALUE  OF  SPECIFIED  F'.C 
: . . -1590  SULFATE  EXPOSURE 


282  CONG  EXPOSED  INJ  SULFATE  MADE  W.  SULFATE -RES  GEM 
: . , -1590  SULFATE  EXPOSURE 
:..-1110  TYPE  OF  CEMENT 

290  REQ  FOR  PERMIS  REDUCTN  IN  REQ'D  AVG  TEST  STRNGTH 

: 1140  QUALITY  OF  TEST  DATA  PER  ACI214-65 

:...1150  PROBABILITY  (STRENGTH  < F'C  - 500) 

:...1160  PROBABILITY  (AVG  OF  3 STRENGTH  TESTS  < F'C) 

300  SAMPLE  STR  TESTS  FOR  EACH  CLASS  OF  CONC  REQ  FREQ 
: . _ 1170  TOTAL  QUANTITY  OF  CONCRETE  PLACED 
: . . . 1180  BUILDING  OFFICIALS  APPROVAL  OF  STRENGTH 
: . . . 1190  STRENGTH  TEST  SAMPLING 
: . . .1200  NUMBER  OF  TESTS  PER  CLASS  OF  CONCRETE 
:..-1210  NUMBER  OF  BATCHES  PER  CLASS  OF  CONCRETE 


330  SAMPLES  FOR  STR  TESTS  TAKEN  IN  ACCORD  ASTM  C172 
: . . . 1600  METHOD  OF  SAMPLING  FRESH  CONCRETE 

340  CYL  MOLDED  & lAB  CURED  SPEC  TESTED  PER  ASTM  C31 
; . . .1610  METH  OF  MAKING  & CURING  CONC  TEST  SPEC  IN  FIELD 

350  CYL  STR  TEST  LAB  CURED  SPEC  TESTED  PER  ASTM  C31 
:..... . -1090  LTB  TEST  PROCEDURE 

380  SOMEONE  SHALL  TAKE  STEPS  TO  INCREASE  STR  OF  CONC 
:....370  ACCEPT  OF  STR  LEVELS  BASED  ON  LAB-CURED  CYL 
:..-1140  QUALITY  OF  TEST  DATA  PER  ACI214-65 
:...1220  NUMBER  OF  TESTS  < (F'C  - 500) 

: . . . 1250  TEST  STRENGTH  OF  LAB  CURED  CYLINDERS 

:...1251  AVG  OF  3 CONSECUTIVE  STR  TESTS  OF  LAB  CURED  CYL 

:..-1550  VALUE  OF  SPECIFIED  F'C 


Figure  A. 4 SASE- generated  global  ingredience  network,  continued. 
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EXTREME  LEVEL  FROM  OUTPUT 

0 

1 2 

3 4 

381 

SOMEONE 

SHALL  TAKE  STEPS -LD  CAP  NOT  JEOPARDIZED 

I • • . “ 

■370*  ACCEPT  OF  STR  LEVELS  BASED  ON  LAB -CURED  CYL 

420  PROC  FOR  PROT  & CURING  CONC  SHALL  BE  ADEQUATE 

. . .1230 

REQ  FOR  STRENGTH  TEST  OF  FIELD  CURED  CYLINDERS 

. . .1240 

METHOD  OF  MOLDING  AND  CURING  FIELD  CURED  CYL 

. . -1250 

TEST  STRENGTH  OF  LAB  CURED  CYLINDERS 

. . .1310 

TEST  STRENGTH  OF  FIELD -CURED  CYLINDERS 

. . -1550 

VALUE  OF  SPECIFIED  F'C 

410 

DEC  BY 

BLDG  OFFL  TO  ORDER  LD  TESTS  OR  OTHER  REQ 

400  ACCEPT  OF  IN  SITU  STR  BASED  ON  CORE  TESTS 

. . .1260 

METHOD  OF  OBTAINING  AND  TESTING  CORES 

. . .1270 

NUMBER  OF  CORES  PER  LOW  STRENGTH  TEST 

. . .1271 

CORE  TEST  STRENGTH 

. . .1280 

3 CORE  TEST  STRENGTH  AVERAGE 

. .-1550 

VALUE  OF  SPECIFIED  F'C 

...1620  METH  OF  LOAD  TESTING  THE  STRUCTURE  (CHAP  20) 

Figure  A. 4 SASE- generated  global  ingredience  network,  concluded. 


143 


COMPLETE  GLOBAL  INGREDIENCE  NETWORK 


EXTREME  LEVEL  FROM  OUTPUT 
0 12  3 4 

181  REQ  THAT  LTB  W/C  RAT  YIELDS  AVG  TEST  STR  IN  60 
: 182  DET  OF  STR  CORR  TO  W/C  RATIO  OF  LTB 


. . .1060 

PREPARATION  OF  LTB  TEST  SPECIMENS 

. . .1070 

LTB 

AIR  CONTENT 

. . .1080 

LTB 

SLUMP 

. . .1090 

LTB 

TEST  PROCEDURE 

60 

DET 

OF  REQUIRED  AVG  TEST  STRNTH  BY  FIELD  EXP 

. . . 1040  STD  DEVIATION  OF  STR  TEST  DATA 

70  DET  OF  STD  DEV  OF  STRENGTH  TEST  DATA 

:...1050  REPRESENTATIVENESS  OF  STRENGTH  TEST  DATA 
;...1290  PREVIOUSLY  SPECIFIED  F'C 
: . . . 1300  BACKGROUND  MATERIALS  AND  PROPORTIONING 
-60*  DET  OF  REQUIRED  AVG  TEST  STRNTH  BY  FIELD  EXP 


Figure  A. 5 Segment  of  SASE- generated  global  ingredience 
network  enlarged  to  illustrate  discussion  of  network 
nomenclature  in  section  A. 3. 3. 
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REFE 

2 

NAME 

STRT 

TYPE 

ACT 

PARE 

74 

TITL 

STRENGTH 

FOSTER: 
COMMENT : 

REFE 

3 

NAME 

BEST 

TYPE 

ACT 

PARE 

59 

TITL 

DESIGN  STRENGTH 

FOSTER: 
COMMENT : 

REFE 

4 

NAME 

ATS 

TYPE 

ACT 

PARE 

6 

TITL 

REQ  AVERAGE  TEST  STRENGTH 

FOSTER: 
COMMENT : 

REFE 

5 

NAME 

HOWS 

TYPE 

ACT 

PARE 

59 

TITL 

SHOWN  ON  DRAWINGS 

FOSTER: 
COMMENT : 

REFE 

6 

NAME 

PROP 

TYPE 

ACT 

PARE 

TITL 

PROPORTIONING 

FOSTER: 
COMMENT : 

REFE 

7 

NAME 

TYPE 

ACT 

PARE 

60 

TITL 

MAKING  AND  CURING  SPECIMENS 

FOSTER: 
COMMENT : 

REFE 

8 

NAME 

TYPE 

PARE 

TITL 

STRENGTH  TEST 

FOSTER: 
COMMENT : 

REFE 

9 

NAME 

woco 

TYPE 

ACT 

PARE 

74 

TITL 

WORKABILITY  & CONSISTENCY 

FOSTER: 
COMMENT : 

Figure  A. 6 SASE-generated  classifier  list  for 
a standard  for  concrete  quality. 
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REFE 

NAME 

TYPE 

PARE 

TITL 

11 

RESF 

ACT 

70 

RESISTANCE  TO  FREEZING 

FOSTER: 
COMMENT : 

REFE 

NAME 

TYPE 

PARE 

TITL 

13 

H20 

ACT 

70 

WATERTIGHT  CONCRETE 

FOSTER: 
COMMENT : 

REFE 

NAME 

TYPE 

PARE 

TITL 

14 

AGE  OF  TEST 

FOSTER: 
COMMENT : 

REFE 

NAME 

TYPE 

PARE 

TITL 

15 

ACT 

2 

SPLITTING  TENSILE  STRENGTH 

FOSTER: 
COMMENT : 

REFE 

NAME 

TYPE 

PARE 

TITL 

16 

IN  ACCORDANCE  WITH  ASTM  C330 

FOSTER: 
COMMENT : 

REFE 

NAME 

TYPE 

PARE 

TITL 

17 

FIELD  EXPERIENCE 

FOSTER: 
COMMENT : 

REFE 

NAME 

TYPE 

PARE 

TITL 

18 

PROPORTIONS 

FOSTER: 
COMMENT : 

REFE 

NAME 

TYPE 

PARE 

TITL 

19 

MINIMUM  ACCEPTABLE  VALUE 

FOSTER: 
COMMENT : 

Figure  A. 6 SASE-generated  classifier  list,  continued. 
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REFE 

21 

NAME 

TYPE 

ACT 

PARE 

4 

TITL 

STANDARD  DEVIATION 

FOSTER; 

COMMENT 

REFE 

23 

NAME 

TYPE 

PARE 

TITL 

IN  ACCORDANCE  WITH  ASTM  C39 

FOSTER: 

COMMENT 

REFE 

26 

NAME 

TYPE 

PARE 

TITL 

LAB  TRIAL  BATCH 

FOSTER: 

COMMENT 

REFE 

32 

NAME 

TYPE 

PARE 

TITL 

ACCEPTABLE  CEMENT  TYPE 

FOSTER; 

COMMENT 

REFE 

33 

NAME 

TYPE 

PARE 

TITL 

NORMAL  WEIGHT  AGGREGATE 

FOSTER: 

COMMENT 

REFE 

35 

FOSTER: 

COMMENT 

NAME 

TYPE 

PARE 

TITL 

ACCEPTABLE  ENTRAINED  AIR  CON 
TENT 

REFE 

36 

NAME 

TYPE 

PARE 

TITL 

MAXIMUM  ALLOWABLE  W/C  RATIO 

FOSTER: 

COMMENT 

REFE 

37 

NAME 

TYPE 

PARE 

TITL 

MINIMUM  DESIGN  STRENGTH 

FOSTER: 

COMMENT 

Figure  A 

6 SASE- 

generated 

classifier  list,  continued. 

147 


REFE 

38 

FOSTER: 
COMMENT : 

NAME 

TYPE 

PARE 

TITL 

LIGHTWEIGHT  AGGREGATE 

REFE 

39 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

70 

TITL 

SULFATE-.  RESISTING  CONCRETE 

REFE 

41 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

65 

TITL 

SAMPLES  FOR  STRENGTH  TESTS 

REFE 

42 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

41 

TITL 

FREQUENCY  OF  SAMPLING 

REFE 

43 

FOSTER: 
COMMENT : 

NAME  _ 

TYPE 

ACT 

PARE 

41 

TITL 

TAKING  OF  SAMPLES  FOR  STRENG 
TH  TESTS 

REFE 

44 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

72 

TITL 

LAB  CURED  TEST  CYLINDERS 

REFE 

45 

FOSTER: 
COMMENT : 

NAME 

TYPE 

PARE 

TITL 

TABLE  4.5 

REFE 

46 

FOSTER: 
COMMENT : 

NAME 

TYPE 

PARE 

TITL 

IN  ACCORDANCE  WITH  ASTM  C31 

Figure  A. 6 SASE-generated  classifier  list,  continued. 
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REFE 

47 

FOSTER: 
COMMENT : 

NAME 

TYPE 

PARE 

TITL 

ADEQUATE  STRENGTH 

REFE 

48 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

65 

TITL 

ACTION  Taken  in  view  of  subs 
TANDARD  STRENGTH  TES 

REFE 

50 

FOSTER: 
COMMENT : 

NAME 

TYPE 

PARE 

TITL 

PROTECTION  AND  CURING 

REFE 

51 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

53 

TITL 

ADEQUATE  PROCEDURES 

REFE 

52 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

53 

TITL 

STRENGTH  OF  CONCRETE 

REFE 

53 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

65 

TITL 

STRENGTH  OF  EXISTING  STRUCTU 
RE 

REFE 

55 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

60 

TITL 

STRENGTH  TESTS  OF  lAB- CURED 
CYLINDERS 

REFE 

56 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

72 

TITL 

FIELD  CURED  TEST  CYLINDERS 

Figure  A. 6 SASE-generated  classifier  list,  continued. 
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REFE 

59 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

2 

TITL 

COMPRESSION  STRENGTH 

REFE 

60 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

65 

TITL 

CYLINDERS 

REFE 

61 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

53 

TITL 

CORES 

REFE 

63 

FOSTER: 
COMMENT : 

NAME 

TYPE 

PARE 

TITL 

W/C  RATIO 

REFE 

65 

FOSTER: 
COMMENT : 

NAME 

TYPE 

PARE 

TITL 

EVALUATION  & ACCEPTANCE  OF  C 
ONCRETE 

REFE 

67 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

73 

TITL 

FIELD  EXPERIENCE  METHOD 

REFE 

68 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

73 

TITL 

LTB  METHOD 

REFE 

69 

NAME 

TYPE 

ACT 

PARE 

73 

TITL 

W/C  RATIO  METHOD 

FOSTER: 
COMMENT : 


Figure  A. 6 SASE- generated  classifier  list,  continued. 
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REFE 

70 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

6 

TITL 

SPECIAL  EXPOSURE  REQUIREMENT 
S 

REFE 

71 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

4 

TITL 

STRENGTH  TEST  DATA 

REFE 

72 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

60 

TITL 

TYPES  OF  CYLINDERS 

REFE 

73 

FOSTER: 
COMMENT : 

NAME 

TYPE 

ACT 

PARE 

6 

TITL 

METHODS  OF  PROPORTIONING 

REFE 

74 

FOSTER: 
COMMENT : 

NAME 

TYPE 

PARE 

TITL 

GENERAL 

Figure  A. 6 SASE- generated  classifier  list,  concluded. 
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CLASSIFIER  PROVISION 

2 

STRENGTH 

3 

DESIGN  STRENGTH 

4 

REQ  AVERAGE  TEST  STRENGTH 

60 

TITL: 

DET  OF  REQUIRED  AVG  TEST 
STRNTH  BY  FIELD  EXP 

70 

TITL: 

DET  OF  STD  DEV  OF  STRENGT 
H TEST  DATA 

290 

TITL: 

REQ  FOR  PERMIS  REDUCTN  OF 
RED'D  AVG  TEST  STRNGTH 

5 

SHOWN  ON  DRAWINGS 

6 

PROPORTIONING 

40 

TITL: 

REQ  TO  PROP  FOR  ADEQ  WORK 
ABILITY  & CONSISTENCY 

60 

TITL: 

DET  OF  REQUIRED  AVG  TEST 
STRENGTH  BY  FIELD  EXP 

181 

TITL: 

REQ  THAT  LTB  W/C  RAT  YIEL 
DS  AVG  TEST  STR  IN  60 

182 

TITL: 

DET  OF  STR  CORR  TO  W/C  RA 
TIO  OF  LTB 

200 

TITL: 

REQ  FOR  MAX  PERMISSIBLE  W 
/C  RATIO  BY  TABLE  4.5 

290 

TITL: 

REQ  FOR  PERMIS  REDUCTN  OF 
REQ'D  AVG  TEST  STRNGTH 

7 

MAKING  AND  CURING  SPECIMENS 

340 

TITL: 

CYL  MOLDED  & LAB  CURED  IN 
ACCORD  WITH  ASTM  C31 

8 

STRENGTH  TEST 

9 

WORKABILITY  & CONSISTENCY 

40 

TITL: 

REQ  TO  PROP  FOR  ADEQ  WORK 
ABILITY  & CONSISTENCY 

11 

RESISTANCE  TO  FREEZING 

230 

TITL: 

CONC  EXPOSED  TO  FREEZ  AIR 
CONT  PER  TBL  4.6.1 

240 

TITL: 

CONC  EXP  TO  FREEZ -MADE  OF 
LT  WT  AGG-F'C>3000PSI 

250 

TITL: 

CONC  EXP  FREEZ -NORM  WT  AG 
G-W/C  RATIO  >0.83 

13 

WATERTIGHT  CONCRETE 

260 

TITL: 

CONC  NORM  WT  AGG  EXPOSED 
FRESH  H20-W/C  RATIO<0 . 5 

261 

TITL: 

CONC  NORM  WT  AGG  EXPOSED 
SEA  H20-W/C  RATIO<=0.45 

270 

TITL: 

CONC  LT  WT  AGG  EXPOSED  FR 
ESH  H20-F'C>3750PSI 

271 

TITL: 

CONC  LT  WT  AGG  EXPOSED  SE 
A H20-F'C  >=4000  PSI 

Figure  A. 7 SASE- generated  scopelist  for  a standard  for  concrete  quality. 
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CLASSIFIER  PROVISION 

14 

AGE  OF  TEST 

01 

TITL; 

STRNTH  TESTS  SHALL  BE  CON 
DUCTED  AT  SPECIFIED  AGE 

15 

SPLITTING  TENSILE  STRENGTH 

20 

TITL: 

REQ  EST  VAL  OF  F(CT)  CORR 
ES  TO  SPEC  VAL  OF  F'C 

16 

IN  ACCORDANCE  WITH  ASTM  C330 

17 

FIELD  EXPERIENCE 

18 

PROPORTIONS 

19 

MINIMUM  ACCEPTABLE  VALUE 

21 

STANDARD  DEVIATION 

23 

IN  ACCORDANCE  WITH  ASTM  C39 

26 

LAB  TRIAL  BATCH 

32 

ACCEPTABLE  CEMENT  TYPE 

33 

NORMAL  WEIGHT  AGGREGATE 

35 

ACCEPTABLE  ENTRAINED  AIR  CONTENT 

36 

MAXIMUM  ALLOWABLE  W/C  RATIO 

37 

MINIMUM  DESIGN  STRENGTH 

38 

LIGHTWEIGHT  AGGREGATE 

39 

SULFATE  RESISTING  CONCRETE 

280 

TITL: 

CONC  NORM  WT  AGG  EXPOS  TO 
SULFATE-W/C  RATI0<=0 . 5 

281 

TITL: 

CONC  LT  WT  AGG  EXPOSED  TO 
SULFATE-F'C  >=3750  PS I 

282 

TITL: 

CONC  EXPOSED  INJ  SULFATE 
MADE  W.  SULFATE  RES  CEM 

41 

SAMPLES  FOR  STRENGTH  TESTS 

300 

TITL: 

SAMPLE  STR  TESTS  FOR  EACH 
CLASS  OF  CONC  REQ  FREQ 

330 

TITL: 

SAMPLES  FOR  STR  TESTS  TAK 
EN  IN  ACCORD  ASTM  C172 

340 

TITL: 

CYL  MOLDED  & LAB  CURED  IN 
ACCORD  WITH  ASTM  C31 

42 

FREQUENCY  OF  SAMPLING 

300 

TITL: 

SAMPLE  STR  TESTS  FOR  EACH 
CLASS  OF  CONC  REQ  FREQ 

43 

TAKING  OF  SAMPLES  FOR  STRENGTH 

TESTS 

330 

TITL: 

SAMPLES  FOR  STR  TESTS  TAK 
EN  IN  ACCORD  ASTM  C172 

44 

LAB  CURED  TEST  CYLINDERS 

45 

TABLE  4.5 

46 

IN  ACCORDANCE  WITH  ASTM  C31 

47 

ADEQUATE  STRENGTH 

Figure  A. 7 SASE- generated  scopelist,  continued. 
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CLASSIFIER 

PROVISION 

48 

ACTION  TAKEN  IN  VIEW  OF 

SUBSTANDARD  STRENGTH  TES 

380 

TITL; 

SOMEONE  SHALL  TAKE  STEPS 
TO  INCREASE  STR  OF  CONC 

381 

TITL: 

SOMEONE  SHALL  TAKE  STEPS - 
■.  LD  CAP  NOT  JEOPARDIZED 

50 

PROTECTION  AND  CURING 

51 

ADEQUATE  PROCEDURES 

410 

TITL; 

DEC  BY  BLDG  OFFL  TO  ORDER 
LD  TESTS  OR  OTHER  REQ 

420 

TITL: 

PROC  FOR  PROT  & CURING  CO 
NC  SHALL  BE  ADEQUATE 

52 

STRENGTH  OF  CONCRETE 

400 

TITL: 

ACCEPT  OF  IN  SITU  STR  BAS 
ED  ON  CORE  TESTS 

53 

STRENGTH  OF  EXISTING  STRUCTURE 

400 

TITL: 

ACCEPT  OF  IN  SITU  STR  BAS 
ED  ON  CORE  TESTS 

410 

TITL; 

DEC  BY  BLDG  OFFL  TO  ORDER 
LD  TESTS  OR  OTHER  REQ 

420 

TITL: 

PROC  FOR  PROT  & CURING  CO 
NC  SHALL  BE  ADEQUATE 

55 

STRENGTH  TESTS  OF  LAB -CURED  CYLINDERS 

350 

TITL: 

CYL  STR  TEST  LAB  CURED  SP 
EC  TESTED  PER  ASTM  C31 

370 

TITL: 

ACCEPT  OF  STR  LEVELS  BASE 
D ON  LAB -CURED  CYL 

56 

FIELD  CURED  TEST  CYLINDERS 

59 

COMPRESSION  STRENGTH 

10 

TITL; 

REQ  FOR  SPEC  OF  CONCRETE 
STRNTH  ON  DES  DRAWING 

60 

CYLINDERS 

61 

CORES 

63 

W/C  RATIO 

181 

TITL; 

REQ  THAT  LTB  W/C  RAT  YIEL 
DS  AVG  TEST  STR  IN  60 

182 

TITL: 

DET  OF  STR  CORR  TO  W/C  RA 
TIO  OF  LTB 

200 

TITL: 

REQ  FOR  MAX  PERMISSIBLE  W 
/C  RATIO  BY  TABLE  4.5 

65 

EVALUATION  & ACCEPTANCE 

OF  CONCRETE 

01 

TITL: 

STRNTH  TESTS  SHALL  BE  CON 
DUCTED  AT  SPECIFIED  AGE 

300 

TITL: 

SAMPLE  STR  TESTS  FOR  EACH 
GLASS  OF  CONC  REQ  FREQ 

Figure  A. 7 SASE-generated  scopelist,  continued. 
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CLASSIFIER 

PROVISION 

(65 

EVALUATION  & ACCEPTANCE 

OF  CONCRETE) 

330 

TITL: 

SAMPLES  FOR  STR  TESTS  TAK 
EN  IN  ACCORD  ASTM  C172 

340 

TITL: 

CYL  MOLDED  & LAB  CURED  IN 
ACCORD  WITH  ASTM  C31 

350 

TITL: 

CYL  STR  TEST  LAB  CURED  SP 
EC  TESTED  PER  ASTM  C31 

370 

TITL; 

ACCEPT  OF  STR  LEVELS  BASE 
D ON  LAB -CURED  CYL 

380 

TITL: 

SOMEONE  SHALL  TAKE  STEPS 
TO  INCREASE  STR  OF  CONC 

381 

TITL: 

SOMEONE  SHALL  TAKE  STEPS - 
LD  CAP  NOT  JEOPARDIZED 

400 

TITL: 

ACCEPT  OF  IN  SITU  STR  BAS 
ED  ON  CORE  TESTS 

410 

TITL: 

DEC  BY  BLDG  OFFL  TO  ORDER 
LD  TESTS  OR  OTHER  REQ 

420 

TITL; 

PROC  FOR  PROT  & CURING  CO 
NC  SHALL  BE  ADEQUATE 

67 

FIELD  EXPERIENCE 

METHOD 

68 

LTB  METHOD 

69 

W/C  RATIO  METHOD 

70 

SPECIAL  EXPOSURE 

REQUIREMENTS 

230 

TITL: 

CONC  EXPOSED  TO  FREEZ  AIR 
CONT  PER  TBL  4.6.1 

240 

TITL; 

CONC  EXP  TO  FREEZ -MADE  OF 
LT  WT  AGG-F'C>3000PSI 

250 

TITL: 

CONC  EXP  FREEZ -NORM  WT  AG 
G-W/C  RATIO  >0.83 

260 

TITL: 

CONC  NORM  WT  AGG  EXPOSED 
FRESH  H20-W/C  RATIO<0 . 5 

261 

TITL: 

CONC  NORM  WT  AGG  EXPOSED 
SEA  H20-W/C  RATIO<=0.45 

270 

TITL: 

CONC  LT  WT  AGG  EXPOSED  FR 
ESH  H20-F'C>3750PSI 

271 

TITL; 

CONC  LT  WT  AGG  EXPOSED  SE 
A H20-F'C  >=4000  PSI 

280 

TITL: 

CONC  NORM  WT  AGG  EXPOS  TO 
SULFATE-W/C  RATIO<=0.5 

281 

TITL: 

CONC  LT  WT  AGG  EXPOSED  TO 
SULFATE-F'C  >=3750  PSI 

282 

TITL; 

CONC  EXPOSED  INJ  SULFATE 
MADE  W.  SULFATE  RES  CEM 

Figure  A. 7 SASE- generated  scopelist,  continued. 
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CLASSIFIER 

PROVISION 

71 

STRENGTH 

TEST  DATA 

72 

TYPES  OF 

CYLINDERS 

73 

METHOD  OF 

PROPORTIONING 

74 

GENERAL 

10 

TITL: 

REQ  FOR  SPEC  OF  CONCRETE 

STRNTH  ON  DES  DRAWING 

20 

TITL: 

REQ  EST  VAL  OF  F(CT)  CORR 

ES  TO  SPEC  VAL  OF  F'C 

30 

TITL: 

REQ  NOT  ACC  CONC  ON  BASIS 

OF  SPLIT  TENSILE  STRNTH 

Figure  A. 7 SASE-generated  scopelist,  concluded. 


ACCEPTABLE  CEMENT  TYPE 
REFE  TITL 

282  CONC  EXP  INJ  SULFATE  MADE  W.  SULFATE -RES  CEM 


ACTION  TAKEN  IN  VIEW  OF  SUBSTANDARD  STRENGTH  TES 
REFE  TITL 

380  SOMEONE  SHALL  TAKE  STEPS  TO  INCREASE  STR  OF  CONC 


REFE  TITL 

381  SOMEONE  SHALL  TAKE  STEPS -LD  CAP  NOT  JEOPARDIZED 


ADEQUATE  PROCEDURES 
REFE  TITL 

410  DEC  BY  BLDG  OFFL  TO  ORDER  LD  TESTS  OR  OTHER  REQ 


REFE  TITL 

420  PROC  FOR  PROT  & CURING  CONC  SHALL  BE  ADEQUATE 


-k'k-krkrk'kitit-k'k-kic^-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k'k'k-k-k-k-k-k-k-k^-k-k^-k-k-k'k-k-k'k-k-k-k'k-Jc'k-k'k-k-k'k-k'k-k'k'k-k-k'kic'k'k'k 

ADEQUATE  STRENGTH 


■k-k-k'k'k-k-k-k-k-k-k'k-k-k-k'k-k-k-k-k-kic-kic-k-k-k'k-k'k-k'k'k-k'k-k-k-k-k-k-k-k-k'k'k-k-k-k-k-k-k-k-k-k-k'k'k-k'k-k-k'k'k-k'k'k'k'k-k'k'k 


AGE  OF  TEST 
REFE  TITL 

01  STRNTH  TESTS  SHALL  BE  CONDUCTED  AT  SPECIFIED  AGE 


'k'k-k-k'k-k-k-k-k-k-k'k-k-k-k-k-k'k-k'k-k-k'k'k'k-k'k-k-k-k-k-k-k*-k-k-k-k-k-k-k'k'k-k'k-k-k-k-k-k-k'k-k-k'k-k-k-k'k-k'k-k:k-k-k'k-k-k'k'k-k 

COMPRESSION  STRENGTH 


REFE  TITL 

10  REQ  FOR  SPEC  OF  CONCRETE  STRNTH  ON  DESIGN  DRAWING 


Figure  A. 8 SASE-generated  index  for 
a standard  for  concrete  quality. 
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CORES 


CYLINDERS 


k^'kick-k'k-k'k-kick'k'k-k-k'k-k-k-k'ki^'k'k'k-k'k-k'k-k'k-k'k-k'k'k-k-k'k'k-k'k'k-k-k'k'k'k-k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'k'kk-k 


DESIGN  STRENGTH 

•k'k-k'k-k-k-k-k'k-k-k^-k-k-k-k-k-krk-k-k-k-k-k-k-k-kirk-k-k-k-k'k-k-k-krkit^-k-k-kit'k-k-k'k-k-k-k'k-k-k-k'k'k'k-k^-k-k-k-k-k'k-k-k-k'k-k 

EVALUATION  & ACCEPTANCE  OF  CONCRETE 


REFE  TITL 

01  STRNTH  TESTS  SHALL  BE  CONDUCTED  AT  SPECIFIED  AGE 


REFE  TITL 

300  SAMPLE  STR  TESTS  FOR  EACH  CLASS  OF  CONC  REQ 


REFE  TITL 

330  SAMPLES  FOR  STR  TESTS  TAKEN  IN  ACCORD  ASTM  C172 


REFE  TITL 

340  CYL  MOLDED  & LAB  CURED  IN  ACCORD  WITH  ASTM  C31 


REFE  TITL 

350  CYL  STR  TEST  LAB  CURED  SPEC  TESTED  PER  ASTM  C39 


REFE 

370 

TITL 

ACCEPT  OF  STR 

LEVELS  BASED  ON  LAB -CURED  CYL 

REFE 

380 

TITL 

SOMEONE  SHALL 

TAKE  STEPS  TO  INCREASE  STR  OF  CONC 

REFE  TITL 

381  SOMEONE  SHALL  TAKE  STEPS -LD  CAP  NOT  JEOPARDIZED 


REFE  TITL 

400  ACCEPT  OF  IN  SITU  STR  BASED  ON  CORE  TESTS 


Figure  A. 8 SASE- generated  index,  continued. 
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(EVALUATION  & ACCEPTANCE  OF  CONCRETE) 

REFE  TITL 

410  DEC  BY  BLDG  OFFL  TO  ORDER  LD  TESTS  OR  OTHER  REQ 


REFE  TITL 

420  PROC  FOR  PROT  & CURING  CONG  SHALL  BE  ADEQUATE 


FIELD  CURED  TEST  CYLINDERS 

k'kkrkkkk'k'kit-k-k'k'k'k-k-k'k'k'k'k'k-kk'k'k'k'k'k'k'k-k-k'k'k'k-kic'k-k-k'k-k'k-k'k-k'k-k'k-k'k-k-k'M'k-k-k-k-k-k'k'k'k'k'k'k'k'k'k'k 

FIELD  EXPERIENCE 

•k-k-kic-k’k-k-k-k-k-k-k-k-kk-k-k-k-k-k-k-k'k'k'k'k-k'k-k-k-k-k-k'kk-k'k'k'k'k-k-k'k'k-k-k'kk'k'k'k'k-k'k'k'k-k'k'k'k'k-k'k'k'k-k'k'k-k'k'k 

FIELD  EXPERIENCE  METHOD 


•k-k-k'k'k-k-k-kk-kk-k'k'k-k'k-k'k-k-k'k'k'k^-k'k-k-k'k'k-k'k-k'k'k'k-k-k-k-k-k-k-k-k'k-k-k-k'kic-k'k-k-k'k-k'k-k'k'k'k'k'k-k'k'k'k'k'k'k'k 

FREQUENCY  OF  SAMPLING 
REFE  TITL 

300  SAMPLE  STR  TESTS  FOR  EACH  CLASS  OF  CONC  REQ  FREQ 


•k-k'k'kkk-kk'k^-k-k'k'k'k'k-k'k-kk-k'kk'kkk-k'k'k-k'k'kk-k-k'kk-k^kk-kic'k-kk'k-k'k-k^k-k-k-k'k-k-k'k-k'kk-k-k-kk-kk'k'k'k'k'k 

GENERAL 

REFE  TITL 

10  REQ  FOR  SPEC  OF  CONCRETE  STRNTH  ON  DES  DRAWING 


REFE  TITL 

20  REQ  EST  VAL  OF  F(CT)  CORRES  TO  SPEC  VAL  OF  F'C 


REFE  TITL 

30  REQ  NOT  ACC  CONC  ON  BASIS  OF  SPLIT  TENSILE  STRNTH 


'kk'k'k'k'k'k'k-k'k-k'k'k'k'k'k'kkk-k'k-k-k'k-k'k-k-k-k'k-k-k'k'k'k-k'k-k-k-k-k'k-k-k'k-k'k'k'k-k-k-k-k-k'k'k'k'k'k-k-k'k'kk'k'k'k'k'k'k'k 

IN  ACCORDANCE  WITH  ASTM  C31 

•kk-k'k'k-k-k-k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k'k-k-k'k-k-k-k'k-k-k'k'k-k-k'k-k-k'k-k-k'k-k-k-k'k-k-kk-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k'k 

IN  ACCORDANCE  WITH  ASTM  C330 


'k-k'k-k'kk'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k'k-k-k-kk-k-k-k-k-k-k-k-k-k-k'k-k'k-k-k-k'k-k-k-k-k-k-k-k'k-k-k-k-k'k-k-k-k-k-k-kk-k'k-k'k'k 


Figure  A. 8 SASE-generated  index,  continued. 
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IN  ACCORDANCE  WITH  ASTM  C39 


lAB  CURED  TEST  CYLINDERS 

'k'k'k-k'k-k-k-k-k-k-k-k-k'k-k-k-k-k'kk'k-kk-k-k-k-k-k'k-kk-k-k-k-k'k-k'k'kk-k-k-k-k'k'k-k-k-k-k-k-k-k-k-k-k-k'k-k'k'k'k-k'k-k-k-k-k'k'k-k 

LAB  TRIAL  BATCH 

•k-k-k-kk-k'k'kirk^-k-k-k-k-k-k-k-k-k-k-k-k-k-k-kk-k-k-kirk-k-k’k-k-k-kirk-k-kk-k-kick-k-k’kick-kirkrk-k'k-k-k'k-k-k-k-k'k-k'k'k'k'k 

LIGHTWEIGHT  AGGREGATE 

•k'k-k'k'k'k'k'k-k'k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k'k-k-krk-k-k-k-k-k-k-k-k^-k-k'k-k-k-k-k-k'k'k-k-k-k'k-k'k'k'k-k-k-k'k'k'k'k'k'k'k-k'k'k-k'k 

LTB  METHOD 

•k'k'k'k-k'k'k'k'k'k'k'k'k-k-k-k-k-k'k-k-k'k'k'k'k-k'k-k-k'k-kirk'k-k-k-k-k'kk’k'k-kk'k-k-k’k'k'kirk-k'k'k'k'k'k'k-k'kk-k'krk'k'k-k-k-k-k 

MAKING  AND  CURING  SPECIMENS 
REFE  TITL 

340  CYL  MOLDED  & LAB  CURED  IN  ACCORD  WITH  ASTM  C31 

•k-k-k-k-kk-k-k-k-k'k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k'k-krk-k'k-k-k-k'k^-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k'k 

MAXIMUM  ALLOWABLE  W/C  RATIO 

'k'k-k'k-k'k'k-k-k-k-k'k-k'k'kic'k'k'k-k-k-k-k-k'k-k'k'k'k-k-k'k-k'k-k-k'k-k-k-k'k-k-k'k'k-kk'k'k'k-k'k-k'k-k'kk'kk'k-k-k'k-k'k-k'k-k-k'k'k 

METHOD  OF  PROPORTIONING 

'k-kk’k'k-kick-k'k-k-k-k-k'k-k-k-k-k-k-krk-k'k-k-k’k-k'k-k-k-k-k-k-k'k-k-k-k-k-k-k'k-kirk-k-k'k-k-k-k'k-k'k-k-k-k-k-k-k-k-k-k-k'k'k'kk-k-k 

MINIMUM  ACCEPTABLE  VALUE 

•k'k-k-k'k-k'kk-kkic^irk-kirkrkirk'k'k'kkic-kick-k-kk-kk^rk-k’k-k-k-kk-k-k'k-k-k-kirk-k’k'k-k-k-k-k-k-k'k'k-k-k-k-k'k-k-k-k'k'k'k 

MINIMUM  DESIGN  STRENGTH 

•k-k-k-k'k-k-k-k-k-k-k-k-k-k'k-kkk'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-kk-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-kk-kk^-krk-k-k'k'k'k-k 

NORMAL  WEIGHT  CONCRETE 

•k^^-k'k-k-k-kifk-k-k-k-k-k-k-k'k-k-k-k-k-k-kk-k-k-k-k-k-k'k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k'k'k-k-k'k-k'k'k'k'k 

PROPORTIONING 
REFE  TITL 

40  REQ  TO  DROP  FOR  ADEQ  WORKABILITY  & CONSISTENCY 


REFE  TITL 

60  DET  OF  REQUIRED  AVG  TEST  STRENGH  TEST  DATA 


Figure  A. 8 SASE- generated  index,  continued. 
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(PROPORTIONING) 


REFE  TITL 

181  REQ  THAT  LTB  W/C  RAT  YIELD  AVG  TEST  STR  IN  60 


REFE 

182 

TITL 

DET  OF  STR  CORR  TO  W/C  RATIO  OF  LTB 

REFE 

200 

TITL 

REQ  FOR  MAX  PERMISSIBLE  W/C  RATIO  BY  TABLE  4.5 

REFE 

290 

TITL 

REQ  FOR  PERMIS  REDUCTN  OF  REQ'D  AVG  TEST 

STRNGTH 

PROPORTIONS 

kic-k'k-k-k-k-k-k-k'k'k'kic'k-k'k'k'k'k'k-k'k'k-k'k-k'k-k'kic-k-k-k'k-k-k-k-k-k-k'k'k-k'kic-k'k-k-k'k-k-k-kic'k-k-k-k'k-k^-k'k'k-k'k-k'k-k'k 

PROTECTION  AND  CURING 

■k'k'kic'k'k-k'k-k'k'k-k'k'k-kick-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k'k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k-k-k'k-k'k'krk'k'k-k'k'k-k'k'k'k'k'k 

REQ  AVERAGE  TEST  STRENGTH 

REFE 

60 

TITL 

DET  OF  REQUIRED  AVG  STRNTH  BY  FIELD  EXP 

REFE 

70 

TITL 

DET  OF  STD  DEV  OF  STRENGTH  TEST  DATA 

REFE 

290 

TITL 

REQ  FOR  PERMIS  REDUCTN  OF  REQ'D  AVG  TEST 

STRNGTH 

'k^-k’k'k-k'k-k-Jrk-k-k-k'k'k'k'k-k-k-k^-k-k^-k-k-k-k-k-k-k^-k-k-k-k-k-k'k'k-k-k-k-k-k-k-k'k'k-k-k-k-k-k-k-k-k-k'k'k-k-k'k'k'k-k'k'k'k'k'k 

RESISTANCE  TO  FREEZING 

REFE 

230 

TITL 

CONC  EXPOSED  TO  FREEZ  AIR  CONT  PER  TBL  4, 

.6.1 

Figure  A. 8 SASE-generated  index,  continued. 
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(RESISTANCE  TO  FREEZING) 


REFE 

240 

TITL 

CONC  EXP  TO  FREEZ-MADE  OF  LT  WT  AGG-F' 03000 

REFE 

250 

TITL 

CONC  EXP  FREEZ-NORM  WT  AGG-W/C  RATIO  >0.83 

SAMPLES  FOR  STRENGTH  TESTS 


REFE 

300 

TITL 

SAMPLE  STR  TESTS  FOR  EACH  CLASS  OF  CONC  REQ  FREQ 

REFE 

330 

TITL 

SAMPLES  FOR  STR  TESTS  TAKEN  IN  ACCORD  ASTM  C172 

REFE 

340 

TITL 

CYL  MOLDED  & LAB  CURED  IN  ACCORD  WITH  ASTM  C31 

icicicieici(ic-k'k'k-k-k'k-/c:k-k'k-k-k-k-J(-k-k'k-k-ki(-k'k-k'k-k-k‘k-k-f:i(-ki(i(-k‘k'k-k‘k-i(-k-k-k-ki(':k-kie-k-ki(-k-k-ki:-ki(-k-k-k-k-k-Jc'k-k 

SHOWN  ON  DRAWINGS 

k'k'k-k'k'k'k-k'k-k-k'k'kkk'k'k-k-kkk-k-k-k-k-k'k-k-k-kk-krk-kit'k-k-kic'k-kkkrk-k-kkic-k-k'k-kkkirk-kk-k'k-k-k-k-k-kk'kkkk'k 

SPECIAL  EXPOSURE  REQUIREMENTS 


REFE 

230 

TITL 

CONC  EXPOSED  TO  FREEZ  AIR  CONT  PER  TBL  4.6.1 

REFE 

240 

TITL 

CONC  EXP  TO  FREEZ-MADE  OF  LT  WT  AGG-F' 03000 

REFE 

250 

TITL 

CONC  EXP  FREEZ-NORM  WT  AGG-W/C  RATIO  >0.83 

REFE 

260 

TITL 

CONC  NORM  WT  AGG  EXPOSED  FRESH  H20-W/C  RATIO<0 . 5 

Figure  A. 8 SASE-generated  index,  continued. 


(SPECIAL  EXPOSURE  REQUIREMENTS) 

REFE 

261 

TITL 

CONC  NORM  WT  AGG  EXPOSED  SEA  H20-W/C  RATIO<=0.45 

REFE 

270 

TITL 

CONC  LT  WT  AGG  EXPOSED  FRESH  H20-F' O3750PSI 

REFE 

271 

TITL 

CONC  LT  WT  AGG  EXPOSED  SEA  H20-F'C  >=4000  PSI 

REFE 

280 

TITL 

CONC  NORM  WT  AGG  EXPOSED  TO  SULFATE-W/C  RATIO<=0 . 5 

REFE 

281 

TITL 

CONC  LT  WT  AGG  EXPOSED  TO  SULFATE-F'C  >=3750  PSI 

REFE 

282 

TITL 

CONC  EXPOSED  INJ  SULFATE  MADE  W.  SULFATE  RES  CEM 

SPLITTING  TENSILE  STRENGTH 

REFE 

20 

TITL 

REQ  EST  VAL  OF  F(CT)  CORRES  TO  SPEC  VAL  OF  F'C 

REFE 

30 

TITL 

REQ  NOT  ACC  CONC  ON  BASIS  OF  SPLIT  TENSILE  STRNTH 

'k'k-k'k-k'k'k'k-kk'k-k-k-k-k-k-k-k-k-k'k'k-k-k-k-k'k-k-k-k-k'k'k'k-k-k-k-k-k-k-k'k'k-k-k'k-k'k'k'k-k'k'k'k-k'k'k-k'k'k-k'k-k'k-k'k'k-k'k'k'k 

STANDARD  DEVIATION 

'k'kk'k'k'k'k-k-k'k'k-k-k'k'k-k-k-k-k'k-k'k'k-k-k'k-k-k'k'k'k'k'k-k-k-k-k-k-k'kk-k-k-k'k'k'k'k'k-k'k'k'k'k'k-k'k'k'k-k'k'k-k'k-k-kk'k'k'k'k 

STRENGTH 

'kk-k-k-k-k-kk-k-k-k-k-krk-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k-k-k-k-k'k-k'k-k-k-k'k'k'k-k-k-k-k-k-k'k-k'k-k'k-k'k-k-k-k-k'k'k'k'k'k'k'k'k 

Figure  A. 8 SASE-generated  index,  continued. 
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STRENGTH  OF  CONCRETE 
REFE  TITL 

400  ACCEPT  OF  IN  SITU  STR  BASED  ON  CORE  TEST 


STRENGTH  OF  EXISTING  STRUCTURE 
REFE  TITL 

400  ACCEPT  OF  IN  SITU  STR  BASED  ON  CORE  TEST 


REFE  TITL 

410  DEC  BY  BLDG  OFFL  TO  ORDER  LD  TESTS  OR  OTHER  REQ 


REFE  TITL 

420  PROC  FOR  PROT  & CURING  CONC  SHALL  BE  ADEQUATE 


•k'k-k-k^^'k-k-k-k-k-k-k'kifk'k'kick-k'kick'k-k-k-k'k'k-k'k-k-k'k-k-k-k'k-k-k'k'k-k-k-kk-k'k-k-k-k-k^-k-k-k-k'k'k-k-k-k'k'k'k-k'k'k-k'k 
STRENGTH  TEST 

•k-k’k’kk'k-k-k-k'k'k'k'k'k-k-k-k'k'k-k'k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k-k-k-k'k'k-k'k-k-k-k-k-krk-k-k-k-k'k-k-k-k'k-k-k'k-k'k^-k'k-k'k'k 

STRENGTH  TEST  DATA 

'k-k-k-k-k-kk-k-kickirk-k'k-kk-k-k-k-k-k-krk^-k-krkirk-k^rk-k-krk:k-k-k-kic-k'kkk-k'k‘kick-k-k-k^-k'k-k-k'k'k-k-k-k-k'k-k'k-k'k-k-k 

STRENGTH  TESTS  OF  LAB -CURED  CYLINDERS 
REFE  TITL 

350  CYL  STR  TEST  LAB  CURED  SPEC  TESTED  PER  ASTM  C39 


REFE  TITL 

370  ACCEPT  OF  STR  LEVELS  BASED  ON  LAB -CURED  CYL 


kickirk'k'k'k-kick'k'k'k'k'k'k-k'k-k-k'k-k-k'k'k-k-kic'k'k-kirk-kk'kk'k'k-k'k-k-k’k'k'k-k-k'kickk'k'k'k'k'k'k-k'k-k-k'k-k-k-k'k-k'k'k 


SULFATE  RESISTING  CONCRETE 


REFE  TITL 

280  CONC  NORM  WT  AGG  EXPOS  TO  SULFATE-W/C  RATI0<0 . 5 


Figure  A. 8 SASE- generated  index,  continued. 
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(SULFATE  RESISTING  CONCRETE) 

REFE 

281 

TITL 

CONC  LT  WT  AGG  EXPOSED  TO  SULFATE-F'C  >=3750  PSI 

REFE 

282 

TITL 

CONC  EXPOSED  INJ  SULFATE  MADE  W.  SULFATE  RES  CEM 

TABLE 

4.5 

■kirk'k-k'k'k'k'k'k'k'k'k'k'kick-k'k'kic'k'k'k'k'k'k'k-k’k'k'k'k'k'k'k'k'k'k-k-k'k'k'k'k-k-k-k-k'k-k-k-k-k'k'k-k-krk-k-k'k-k-k'k'k-k'k'k'k'k 

TAKING  OF  SAMPLES  FOR  STRENGTH  TESTS 

REFE 

330 

TITL 

SAMPLES  FOR  STR  TESTS  TAKEN  IN  ACCORD  ASTM  C172 

•k-krk-k-k-k-k-krk-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k'k-k-k-k'k'k'kic-k'kirk'k-k'k^rk-krk-k-k-k-k-k-k-k-k-k'k-k-k-k-k-k'k-k'k-k'k-k-k-k'k-k-k'k 

TYPES 

OF  CYLINDERS 

•k'k-k^-k-k-k-k'k'k-k'kirk'k^-k^'k'k-k-k'kirk-k-k-k-krk-k-k-k-k-k'k-k-k-k-k'k'k-k-k'k-k-k'k'k'k-k-k'k-k-k'k-k-krk'k'k-k'k-k-k'k'k'k'k'k'k 

WATERTIGHT  CONCRETE 

REFE 

260 

TITL 

CONC  NORM  WT  AGG  EXPOSED  FRESH  H20-W/C  RATIO<0 . 5 

REFE 

261 

TITL 

NORM  WT  AGG  EXPOSED  SEA  H20-W/C  RATIO<=0.45 

REFE 

270 

TITL 

CONC  LT  WT  AGG  EXPOSED  FRESH  H20-F' O3750PSI 

REFE 

271 

TITL 

CONC  LT  WT  AGG  EXPOSED  SEA  H20-F'C  >=4000  PSI 

■k-k-k-k-k-k-kic-k-k-k-k-k-k-k'k-k-k-k-k'k-k-k-k'k-k'k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k-k^-k'k-k'k-k'k'k-k-k-k-k'k-k-k'k-k'k'k 

Figure  A. 8 SASE- generated  outline,  continued. 
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WORKABILITY  & CONSISTENCY 
REFE  TITL 

40  REQ  TO  PROP  FOR  ADEQ  WORKABILITY  & CONSISTENCY 


W/C  RATIO 
REFE  TITL 

181  REQ  THAT  LTB  W/C  RAT  YIELDS  AVG  TEST  STR  IN  60 


REFE  TITL 

182  DET  OF  STR  CORR  TO  W/C  RATIO  OF  LTB 
REFE  TITL 

200  REQ  FOR  MAX  PERMISSIBLE  W/C  RATIO  BY  TABLE  4.5 


'k'k-kk-k'k'k'k-kk-kk-k-k'k-kk-k-kk'k'k-k-k-kk'k-kk-k-k-kk-k-k'k-k-k-k-k-k-k-k-k-k-k'k'k'k'k'k-kk-k-k-kk-k'k'k-k-k'k-k-k-k-k'k'k'k'k 

W/C  RATIO  METHOD 

'k'k'kk'k'k-k-k-k-k-kick-k'k'k'kirk'k'k-k-k-k-k'k'k-k-k-kkk-k'k-k'k-k-k'k-k-k-k-k-k-k-k-k-k-k'k'k'k'k'k'k-k'k'k'k'k'k'k'k'k'k'k-k'k'k'k'k 


Figure  A. 8 SASE- generated  index,  concluded. 
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CLASSIFIER  PROVISION 

74 

GENERAL 

59 

COMPRESSION  STRENGTH 

10 

TITL: 

REQ  FOR  SPEC  OF  CONCRETE 
STRNTH  ON  DES  DRAWING 

15 

SPLITTING  TENSILE  STRENGTH 

20 

TITL: 

REQ  EST  VAL  OF  F(CT)  CORR 
ES  TO  SPEC  VAL  OF  F'C 

6 

PROPORTIONING 

9 

WORKABILITY  & CONSISTENCY 

40 

TITL: 

REQ  TO  PROP  FOR  ADEQ  WORK 
ABILITY  & CONSISTENCY 

4 

REQ  AVERAGE  TEST  STRENGTH 

60 

TITL: 

DET  OF  REQUIRED  AVG  STRNT 
H BY  FIELD  EXP 

70 

TITL: 

DET  OF  STD  DEV  OF  STRENGT 
H TEST  DATA 

290 

TITL: 

REQ  FOR  PERMIS  REDUCTN  OF 
REQ'D  AVG  TEST  STRNGTH 

63 

W/C  RATIO 

181 

TITL: 

REQ  THAT  LTB  W/C  RAT  YIEL 
DS  AVG  TEST  STR  IN  60 

182 

TITL: 

DET  OF  STR  CORR  TO  W/C  RA 
TIO  OF  LTB 

200 

TITL: 

REQ  FOR  MAX  PERMISSIBLE  W 
/C  RATIO  BY  TABLE  4.5 

70 

SPECIAL  EXPOSURE  REQUIREMENTS 

11  RESISTANCE  TO  FREEZING 

230 

TITL: 

CONC  EXPOSED  TO  FREEZ  AIR 
CONT  PER  TBL  4.6.1 

240 

TITL: 

CONC  EXP  TO  FREEZ -MADE  OF 
LT  WT  AGG-F' 03000 

250 

TITL: 

CONC  EXP  FREEZ -NORM  WT  AG 
G-W/C  RATIO  >0.83 

13  WATERTIGHT  CONCRETE 

260 

TITL: 

CONC  NORM  WT  AGG  EXPOSED 
FRESH  H20-W/C  RATIO<0 . 5 

261 

TITL: 

CONC  NORM  WT  AGG  EXPOSED 
SEA  H20-W/G  RATIO<0.45 

270 

TITL: 

CONC  LT  WT  AGG  EXPOSED  FR 
ESH  H20-F'C>3750PSI 

271 

TITL: 

CONC  LT  WT  AGG  EXPOSED  SE 
A H20-F'C  > 4000  PSI 

Figure  A. 9 SASE- generated  outline  for  a standard  for  concrete  quality. 
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CLASSIFIER 

PROVISION 

(6 

PROPORTIONING) 

(70 

SPECIAL  EXPOSURE  REQUIREMENTS) 

39 

SULFATE  RESISTING  CONCRETE 

280 

TITL: 

CONC  NORM  WT  AGG  EXPOS  TO 
SULFATE-W/C  RATIO<=0 . 5 

281 

TITL: 

CONC  LT  WT  AGG  EXPOSED  TO 
SULFATE- F'C  > 3750  PS I 

282 

TITL: 

CONC  EXPOSED  INJ  SULFATE 
MADE  W.  SULFATE  RES  CEM 

65 

EVALUATION  & ACCEPTANCE  OF 

CONCRETE 

41 

SAMPLES  FOR  STRENGTH  TESTS 

42 

FREQUENCY  OF  SAMPLING 

300 

TITL: 

SAMPLE  STR  TESTS  FOR  EACH 
CLASS  OF  CONC  REQ  FREQ 

43 

TAKING  OF  SAMPLES  FOR 

STRENGTH 

TESTS 

330 

TITL: 

SAMPLES  FOR  STR  TESTS  TAK 
EN  IN  ACCORD  ASTM  C172 

7 

MAKING  AND  CURING  SPECIMENS 

340 

TITL: 

CYL  MOLDED  & LAB  CURED  IN 
ACCORD  WITH  ASTM  C31 

14 

AGE  OF  TEST 

01 

TITL: 

STRNTH  TESTS  SHALL  BE  CON 
DUCTED  AT  SPECIFIED  AGE 

55 

STRENGTH  TESTS  OF  LAB -CURED  CYLINDERS 

350 

TITL: 

CYL  STR  TEST  LAB  CURED  SP 
EC  TESTED  PER  ASTM  C31 

370 

TITL: 

ACCEPT  OF  STR  LEVELS  BASE 
D ON  LAB -CURED  CYL 

48 

ACTION  TAKEN  IN  VIEW  OF 

SUBSTANDARD  STRENGTH  TES 

380 

TITL: 

SOMEONE  SHALL  TAKE  STEPS 
TO  INCREASE  STR  OF  CONC 

381 

TITL: 

SOMEONE  SHALL  TAKE  STEPS- 

LD  CAP  NOT  JEOPARDIZED 

53 

STRENGTH  OF  EXISTING  STRUCTURE 

51 

ADEQUATE  PROCEDURES 

410 

TITL: 

DEC  BY  BLDG  OFFL  TO  ORDER 
LD  TESTS  OR  OTHER  REQ 

420 

TITL: 

PROC  FOR  PROT  & CURING  CO 
NC  SHALL  BE  ADEQUATE 

52 

STRENGTH  OF  CONCRETE 

400 

TITL: 

ACCEPT  OF  IN  SITU  STR  BAS 
ED  ON  CORE  TEST 

Figure  A. 9 SASE- generated  outline,  concluded. 
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Table  A.l  Requirement  for  strength  tests  at  specified  age  (datum  1) 


DECISION  TABLE 


1 2 3 E ELSE:  RUL  123 


1 HI -EARLY  CONCRETE  * T F F 

2 TEST  AGE  = 28  DAYS  * . T F 

3 TEST  AGE  AS  SPECIFIED  * t + T . 

1 REQ  FOR  TEST  AGE  = SAT.  * X X X 

2 REQ  = VIOLATED  * X 


Cl  T T F 

C 2 T F F 

C 3 F F F 


Table  A. 2 Requirement  establishing  the  value  of  f^t  corresponding 
to  specified  value  of  f'^  (datum  20) 


DECISION  TABLE 


1 E ELSE:  RUL  1 2 


1 DESIGN  GRIT  PERMIT  USE  OF  F(  * T C 1 T F 

CT)  * C 2 T . 

2 LAB  TESTS  IN  ACCORD  WITH  AST  * T 

M C330  * 

**■**■*•* -st  ■jSr '*■* 'st'jt'*’ ■*•■*■*■5!:  •*■*•*■**■*  ■*■*•*■*•*■*•* -sir 

1 REQ  EST  VAL  OF  F(CT)  = SAT.  * X 

2 REQ  = VIOLATED  * X 


Table  A. 3 Determination  of  required  average  test  strength  (datum  60) 


1 REQ  AVG  TEST  STR  = F'C+400 

2 REQ  AVG  TEST  STR  = F'C+550 

3 REQ  AVG  TEST  STR  = F'C+700 

4 REQ  AVG  TEST  STR  = F'C+900 

5 REQ  AVG  TEST  STR  = F'C+1200 


■* 

* 

* 

* 

* 


X 


X 


X 


X 


X X 


DECISION  TABLE 

1 

2 

3 

4 

5 

6 

ELSE: 

RUL 

1 

1 

STDEV  < 300 

■k 

T 

- 

- 

- 

- 

- 

C 

1 

F 

2 

300<=  STDEV  <400 

■k 

- 

T 

- 

- 

- 

- 

C 

2 

F 

3 

400<=  STDEV  <500 

k 

- 

- 

T 

- 

- 

- 

C 

3 

F 

4 

500<=  STDEV  <600 

k 

- 

- 

- 

T 

- 

- 

C 

4 

F 

5 

STDEV  > 600 

k 

- 

- 

- 

- 

T 

- 

C 

5 

F 

6 

STDEV  NOT  DEFINED 

* 

- 

- 

- 

- 

- 

T 

C 

6 

F 

'•k'k'k'k 

169 


Table  A. 4 Determination  of  standard  deviation  of  strength  test  data  (datum  70) 


DECISION  TABLE 

1 

2 E 

E:  RUL 

1 

2 

3 

4 

5 

6 

7 

1 

DATA  REPRESENTS  >=  30  CONSEC 

* 

T 

C 

1 

T 

T 

T 

T 

F 

F 

F 

UTIVE  TESTS 

* 

C 

2 

T 

T 

F 

F 

T 

T 

F 

2 

DATA  ARE  STAT  AVG  OF  2 GROUP 

■* 

- 

T 

c 

3 

T 

F 

T 

F 

T 

F 

S T0T5«  30  TESTS 

* 

c 

4 

F 

F 

F 

3 

BACKGROUND  SIR  TESTS  REP  CON 

* 

T 

T 

C PRODUCED  FOR  F'C(BT)  SUCH 

•* 

THAT  (F'C-1000)<=F'C(BT)<=(F 

■k 

'C+1000) 

4 

BACKGROUND  MATERIALS  & PROPO 

k 

T 

T 

RTIONS  ARE  NOT  MORE  CLOSELY  * 
RESTRICTED  THAT  FOR  PROPOSED  * 
WORK  * 


1 STDEV  COMPUTED  BY  STATISTICS  * X X 

2 STDEV  NOT  DEFINED  * X 


Table  A.  5 Determination  of  strength  corresponding  to  water- cement 
ratio  of  laboratory  trial  batch  (datum  182) 


DECISION  TABLE 


E ELSE;  RUL  1 2 3 


1 CURVE  BASED  ON  >=3  PTS  REPG  * T 

BATCHES  W/STR  +/-  THAT  GIVEN  * 

BY  DATUM  60  * 

2 EACH  PT  BASED  ON  >-  3 CYLS  M * T 

ADE  PER  ASTM  C192  & TESTED  P * 

ER  ASTM  C39  * 

3 BATCH  AIR  = +/-  0.5%  & TACH  * T 

SLUMP  = +/-  0.75  IN  OF  MAX  A * 

LLOWED  * 

1 STRENGTH  GIVEN  BY  CURVE  X 

2 STRENGTH  NOT  DETERMINED  * X 


Cl  T T F 

C 2 T F . 

C 3 F . . 
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Table  A. 6 Requirement  for  maximum  permissible  w/c  ratio 
by  table  4.5  (datum  200) 


DECISION  TABLE 


E ELSE:  RUL  1234 


1 SUITABLE  DATA  NOT  AVAILABLE  * T 

FROM  FIELD  EXPERIENCE  OR  LTB  * 

AND  PERMISSION  GRANTED  BY  (?  * 

) TO  USE  W/C  RATIO  LIMITS  * 

2 CEMENT  IS  TYPE  I,  lA,  II,  II  * T 

A,  III,  IIIA,  OR  V PER  ASTM  * 

C150,  OR  TYPE  IS,  IS-A,  IS(M  * 

S),  IS-A(MS),  IP,  IP-A,  OR  P * 

, PER  ASTM  C595  * 

3 CONCRETE  CONTAINS  LIGHTWEIGH  * F 

T AGGREGATE  * 

4 CONCRETE  CONTAINS  ADMIXTURE  * F 

OTHER  THAN  ENTRAINED  AIR  * 

1 REQ  FOR  MAX  PERMISSIBLE  W/C  * X 

RATIO  BY  TABLE  4.5  = SAT.  * 

2 REQ  = VIOLATED  * X 


Cl  T T T F 

C 2 T T F . 

C 3 T F . . 

C 4 . T . . 


Table  A. 7 Requirement  for  permissible  reduction  of  average 
test  strength  (datum  290) 


DECISION  TABLE 


E ELSE:  RUL  123 


1 TEST  DATA  MEETS  ACI214-65  * T 

2 PROB.  [STR<F'C-500]  < .01  * T 

3 PROB.  [(AVG  OF  3 STR  TESTS)<  * T 

F'C]  < .01  * 

1 REQ  FOR  PERMIS  REDUCT  OF  REQ  * X 

'D  AVG  TEST  STR  (CF  ACI214-  * 

65)  = SATISFIED  * 

2 REQ  = VIOLATED  * X 


Cl  T T F 

C 2 T F . 

C 3 F . . 
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Table  A. 9 Requirement  for  the  frequency  of  strength  test  samples 
taken  for  each  class  of  concrete  (datum  300) 

DECISION  TABLE  1 2 3 ' E E:  RUL  1234 


1 TOTAL  QUANTITY  OF  EACH  CLASS  * T F , F 

< 50  CYL  & STR  TEST  WAIVED  B * 

Y BLDG  OFFL  BASED  ON  EVIDENC  * 

E OF  SATISFACTORY  STRENGTH  * 

2 CONC  SAMPLED  >=  1/DAY  OF  PLA  * . T T 

CEMENT  * 

3 CONC  SAMPLED  >=1/150  CYL  * . T T 

4 CONC  SAMPLED  >=  1/5000  SF  OF  * . T T 

SLAB  OR  FLOOR  SURFACE  * 

5 PROVIDES  >=  5 STR  TESTS,  EAC  * . T F 

H OF  2 CYLS/SAMPLE  * 

6 STR  TESTS  MADE  FROM  >=  5 RAN  * . . T 

DOMLY  SELECTED  BATCHES,  OR  F * 

ROM  EACH  BATCH  IF  BATCHES  <5  * 

•k'k'k'k'k'k'k'k'k'k-kicJcic'k'JdcJckic'JrJc'k'k'k'k'k'k'Jck'k'k-k-k'k'Jc'k-k-k-k-k'kick'k-k 

1 REQ  FOR  FREQ  OF  STR  TEST  SA  * X X X 

MPLES  = SATISFIED  * 

2 REQ  = VIOLATED  * X 


Cl  F F F F 

C 2 T T T F 

C 3 T T F . 

C 4 T F . . 

C 5 F . . . 

C 6 F . . . 


Table  A. 9 Requirement  for  strength  levels  based  on  lab -cured 
cylinders  (datum  370) 


DECISION  TABLE  1 E ELSE:  RUL  1 2 


1 AVG  OF  ALL  SETS  OF  3 CONSECU  * T C 1 T F 

TIVE  STR  TESTS  >=  F'C  * C 2 F . 

2 NO  SINGLE  TEST  <[F'C-500]  * T 

*'>***■*■*'**■*'*■**■*'*■)!:■*■*■*'*■*■*■*■)(:•*■  "it  ■*■*■*■*■*■*■*■•)(:■*•!!!■  ■*■*•*■*■* 

1 REQ  FOR  STR  LEVELS  = SAT.  * X 

2 REQ  = VIOLATED  * X 
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Table  A. 10  Acceptability  of  in-situ  strength  based  on  core  tests  (datum  400) 


DECISION  TABLE  1 E 


1 CORES  OBTAINED  AND  TESTED  P * T 

ER  ASTM  C42  * 

2 THREE  CORES  PER  LOW  STR  TEST  * T 

3 AIR  DRIED  7 DAYS  & TESTED  DR  * T 

Y IF  DRY  IN  SERVICE,  OR  IMME  * 

RSED  48  HRS  AND  TESTED  WET  I * 

F WET  IN  SERVICE  * 

4 [AVG  OF  3 CORES ]>=.85F'C  AND  * T 

NO  CORE  < .75F'C  * 

1 STRUCTURAL  ADEQUACY  BY  CORE  * X 

TEST  = SATISFIED  * 

2 STRUCTURAL  ADEQUACY  BY  CORE  * X 

TEST  = NOT  SATISFIED  * 


ELSE;  RUL  1234 


Cl  T T T F 

C 2 T T F F 

C 3 T F . . 

C 4 F . . . 


Table  A. 11  Requirement  for  the  protection  and  curing  of  concrete  (datum  420) 


DECISION  TABLE 

1 

2 

3 E 

• ELSE: 

RUL 

1 

2 

3 

1 

BLDG  OFFL  REQUIRES  STR  TEST 

* 

F 

T 

T 

C 

1 

T 

T 

T 

OF  FIELD  CURED  CYLINDERS 

* 

C 

2 

T 

T 

F 

2 

FIELD  CURED  CYLINDERS  CURED 

* 

T 

T 

C 

3 

T 

F 

BY  SEC  7.4  OF  ASTM  C31 

* 

C 

4 

F 

3 

FIELD  CURED  CYLINDERS  MOLDED 

* 

T 

T 

C 

5 

F 

AT  SAME  TIME  AMD  FROM  SAME  S 

* 

AMPLES  AS  LAB  CURED 

4 

STR  < .85  LAB  CURED  CYLS . 

* 

T 

F 

5 

STR  >=F'C+500 

■* 

'k-k 

'k-k-k-k'k-k-k-k-k'k'k-k-k'k'k-k'k'k-k-k'k'k'k'k^'k'k'k'k-k- 

k-k-k-k'k-k 

*** 

k'k'k'k'k 

1 

REQ  FOR  PROTECTION  AND  CURIN 

'k 

X 

X 

X 

G OF  CONC  = SATISFIED  * 

2 REQ  = VIOLATED  * X 
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APPENDIX  B.  ANNOTATED  BIBLIOGRAPHY 


The  concepts  presented  in  the  report  are  the  results  of  the  work  of  several 
groups  of  researchers  over  the  last  20  years.  The  most  significant 
research  reports  and  papers  are  presented  below  in  chronological  order, 
with  brief  explanatory  comments.  The  reader  should  be  warned  that  this 
work  represents  evolutionary  growth  in  a new  area;  in  particular,  the 
terminology  used  has  changed  over  the  years. 

[1]  Fenves,  S.  J.,  "Tabular  Decision  Logic  for  Structural  Design," 
Journal  of  the  Structural  Division.  Vol.  92,  No.  ST6  (New  York; 
American  Society  of  Civil  Engineers,  1966),  pp.  473-490. 

First  discussion  of  the  use  of  decision  tables  to  represent  provi- 
sions of  design  specifications. 

[2]  Fenves,  S.  J.,  Gaylord,  E.  H.  , Jr.,  and  Goel,  S.  K.  , "Decision 

Table  Formulation  of  the  1969  American  Institute  of  Steel  Construc- 
tion Specification,"  Civil  Engineering  Studies.  No.  SRS  347 
(Urbana:  University  of  Illinois,  1969). 

First  major  application  of  [1]  to  a design  specification.  Intro- 
duces the  concept  of  "switching  tables"  to  represent  the  organiza- 
tion or  outline,  "testing  tables"  for  evaluating  requirements,  and 
"working  tables"  to  evaluate  determinations. 

[3]  Goel,  S.  K.  , and  Fenves,  S.  J.,  "Computer-Aided  Processing  of 

Design  Specifications,"  Journal  of  the  Structural  Division.  Vol. 
97,  No.  STl  (New  York:  American  Society  of  Civil  Engineers,  1971), 

pp.  463-479. 

Description  of  a program  for  execution  of  decision  tables  described 
in  [2] . Introduces  concept  of  "direct  execution"  and  "condition 
execution" . 

[4]  Wright,  R.  N. , Boyer,  L.  T. , and  Melin,  J.  W. , "Constraint  Process- 
ing in  Design,"  Journal  of  the  Structural  Division.  Vol.  97,  No. 

STl  (New  York:  American  Society  of  Civil  Engineers,  1971),  pp . 
481-494. 

Introduces  distinction  between  criterion  in  a design  specification 
and  its  application  in  a specific  instance,  termed  "constraint". 

[5]  Seeberg,  P.  , "Decision  Table  Formulation  of  the  Specification  for 
the  Design  of  Cold-Formed  Steel  Structural  Members"  (Milwaukee: 
University  of  Wisconsin,  1971) . 

A major  application  patterned  directly  after  [2]. 

[6]  Fenves,  S.  J.,  "Representation  of  the  Computer-Aided  Design  Process 

by  a Network  of  Decision  Tables,"  Computer  and  Structures.  Vol.  3, 
No.  5 (New  York:  Pergamon  Press,  1973),  pp . 1099-1107. 
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Combination  of  concepts  from  [3]  and  [4],  generalizing  the  process 
of  conditional  execution. 

[7]  Fenves,  S.  J.,  D.  J.  Nyman,  and  R.  N.  Wright,  "Reformulation  of  the 

Decision  Tables  for  the  1969  AISC  Specification" , Unpublished 
progress  report  (Urbana:  University  of  Illinois,  July,  1972). 

Reformulated  tables  from  [2],  with  each  decision  table  producing 
one  datum. 

[8]  Nyman,  D.  J.,  S.  J.  Fenves,  and  R.  N.  Wright,  "Restructuring  Study 
of  the  AISC  Specification",  Civil  Eneineering  Studies.  No.  SRS  393 
(Urbana;  University  of  Illinois,  1973). 

First  study  devoted  exclusively  to  formulation  and  organization  of 
a design  specification.  Introduces  "functional  network"  and 

"organizational  network";  three  levels  of  analysis  and  organiza- 
tion, (subsequently  named  outline,  information  network,  and 

decision  tables) . 

[9]  Nyman,  D.  J.  and  Fenves,  S.  J.,  "An  Organization  Model  for  Design 

Specifications,"  Journal  of  the  Structural  Division.  Vol.  101,  No. 
ST4  (New  York:  American  Society  of  Civil  Engineers,  1975),  pp . 

697-716. 

Major  extension  of  [8],  introducing  organization  strategies  for 
outlines  and  information  network,  exploring  strategies  for  genera- 
ting textual  expressions. 

[10]  Noland,  J.  L.  and  Feng,  C.  C.,  "American  Concrete  Institute 
Building  Code  in  Decision  Logic  Table  Format,"  Journal  of  the 
Structural  Division.  Vol.  101,  No.  ST4  (New  York;  American  Society 
of  Civil  Engineers,  1975),  pp . 677-696. 

A major  application  patterned  after  [2]  , but  introducing  a number 
of  new  concepts,  including  "active"  design  tables  instead  of 
"passive"  testing  tables  for  evaluating  criteria. 

[11]  Harris,  J.  R. , J.  W.  Melin,  R.  L.  Tavis , and  R.  N.  Wright,  "Techno- 

logy for  the  Formulation  and  Expression  of  Specifications,  Volume 
I:  Final  Report,"  Civil  Engineering  Studies.  No.  SRS  423  (Urbana: 

University  of  Illinois,  1975). 

Harris,  J.  R. , J.  W.  Melin,  R.  L.  Tavis,  and  R.  N.  Wright,  "Techno- 
logy for  the  Formulation  and  Expression  of  Specifications,  Volume 
II:  Program  User's  Manual,"  Civil  Engineering  Studies.  No.  SRS  424 

(Urbana;  University  of  Illinois,  1975). 

Harris,  J.  R. , J.  W.  Melin,  R.  L.  Tavis,  and  R.  N.  Wright,  "Techno- 
logy for  the  Formulation  and  Expression  of  Specifications,  Volume 
III;  Technical  Reference  Manual,"  Civil  Engineering  Studies.  No. 
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SRS  425  (Urbana:  University  of  Illinois,  1975). 


Documentation  of  methodology  and  program  developed  up  to  1975. 
Tutorial  material  on  decision  tables,  decision  trees,  and  informa- 
tion networks  used  in  chapters  4,  5,  and  7. 

[12]  Wu,  S.  K.  F.  and  D.  W.  Murray,  "Decision  Table  Processing  of  the 

Canadian  Standards  Association  Specification  S16.1",  Structural 
Engineering  Report  No.  52  (Edmonton,  Canada:  University  of 

Alberta,  1976) . 

A major  application  patterned  after  [2]  and  [3]  , including  a 
modified  program  for  executing  decision  tables. 

[13]  Fenves , S.  J.,  K.  Rankin,  and  H.  Tejuja,  The  Structure  of  Building 

Specifications . Building  Science  Series  90  (Washington:  National 

Bureau  of  Standards,  1976). 

Extension  of  previous  studies  to  performance  and  prescriptive 
specifications.  First  general  formulation  of  requirements. 

[14]  Fenves,  S.  J.,  and  R.  N.  Wright,  The  Representation  and  Use  of 

Design  Specifications.  Technical  Note  940  (Washington:  National 

Bureau  of  Standards,  1977). 

A synthesis  of  previous  studies,  introducing  strategies  for 
analysis  and  synthesis,  distinguishing  between  formulation, 
expression  and  use. 

[15]  Nyman,  D.  J.,  J.  D.  Mozer,  and  S.  J.  Fenves,  "Decision  Table 
Formulation  of  the  Load  and  Resistance  Factor  Design  Criteria," 
Report  R-77-6,  Department  of  Civil  Engineering  (Pittsburgh: 
Carnegie-Mellon  University,  1977). 

A major  application  patterned  after  [2]  and  [9]. 

[16]  Cunningham,  L.  K. , J.  W.  Melin,  and  R.  L.  Tavis,  "Detailed  Applica- 

tion of  a Technology  for  the  Formulation  and  Expression  of  Stan- 
dards," Civil  Engineering  Studies  No.  SRS  446,  (Urbana:  University 

of  Illinois,  1978). 

A tutorial  case  study  on  a very  detailed  level  of  analysis. 

[17]  Harris,  J.  R. , S.  J.  Fenves,  and  R.  N.  Wright,  Analysis  and  Tenta- 

tive Seismic  Design  Provisions  for  Buildings.  NBS  Technical  Note 
1100  (Washington:  National  Bureau  of  Standards,  1979). 

The  largest  application  to  date. 

[18]  Fenves,  S.  J.,  "Recent  Developments  in  the  Methodology  for  the 

Formulation  and  Organization  of  Design  Specifications,"  Int . J.  of 
Engineering  Structures.  Vol.  1,  No.  5 (London:  IPC  Science  and 
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Technology  Press,  1979)  pp . 223-229. 

A summary  of  [15]. 

Rasdorf,  W,  J.  and  S.  J.  Fenves,  "Representation  and  Analysis  of 
Design  Specifications  at  the  Interface  Between  Outlines,  Networks, 
and  Decision  Tables,"  Report  R-127-879,  Department  of  Civil  Engi- 
neering (Pittsburgh:  Carnegie-Mellon  University,  1979) . 

Procedures  for  splitting,  expanding  and  compressing  decision  tables 
and  making  corresponding  changes  in  information  network  and 
outline. 


Harris,  J.  R.  and  R.  N.  Wright,  Organization  of  Building  Standards 
Building  Science  Series  136  (Washington:  National  Bureau  of 
Standards,  1981). 


Major  survey  of  previous  work  and  classification  schemes  and 
criteria  and  methods  for  organizing  specifications.  Tutorial 
material  on  provisions,  classifiers,  organizations,  and  outlines 
extensively  used  in  chapters  8 through  13. 

Fenves,  S.  J,,  "Software  for  Analysis  of  Standards,"  Computing  in 
Civil  Engineering  (New  York:  American  Society  of  Civil  Engineers, 
1980) . 


Summary  of  specification  for  SASE  program. 

Holtz,  N.  M.  and  S.  J.  Fenves,  "Using  Design  Specifications  for 
Design,"  ibid,  pp.  92-101. 

Extension  of  methodology  to  symbolically  reformulate  specifications 
presented  in  checking  mode  into  constraints  on  design  variables. 

Rasdorf,  W.  and  S.  J.  Fenves,  "Design  Specification  Representation 
and  Analysis,"  ibid,  pp.  102-111. 

A summary  of  [19]. 

Harris,  J.  R. , "Organization  of  Design  Standards,"  ibid,  pp . 
112-123. 


A sximmary  of  [20]  . 

Harris,  J.  R.  , S.  J.  Fenves,  and  R.  N.  Wright,  "New  Tools  for 
Standard  Writers,"  Standardization  News.  Vol.  8,  No.  7 (Philadel- 
phia: American  Society  for  Testing  and  Materials,  1980),  pp . 10-17. 

A summary  of  methods  used  in  [17]. 

Harris,  J.  R. , S.  J.  Fenves,  and  R.  N.  Wright,  "Logical  Analysis  of 
Tentative  Seismic  Provisions,"  J.  of  the  Structural  Division.  Vol. 


107,  No.  STS  (New  York;  American  Society  of  Civil  Engineers, 
1981),  pp.  1629-1641. 

A summary  of  findings  from  [17]. 

[27]  Tavis,  R.  L.  and  J.  W.  Melin,  "Use  of  Technical  Analysis  in  Edi- 
ting," Civil  Engineering  Studies  No.  SRS  473  (Urbana:  University 

of  Illinois,  1980). 

A follow-up  on  [16] , concentrating  primarily  on  editing  (called 
"expression"  in  this  report) . 

[28]  Stirk,  J.  A.,  "Two  Software  Aids  for  Design  Specification  Use," 

Unpublished  M.S.  Thesis  (Pittsburgh:  Carnegie -Mellon  University, 

1981) . 

A complete  revision  of  the  programs  described  in  [2]  and  [17]  for 
the  conditional  and  direct  execution  of  networks  of  decision 
tables . 

[29]  Fenves,  S.  J.,  "A  Methodology  for  the  Evaluation  of  Designs  for 
Standards  Conformance,"  Proceedings  of  lABSE  Symposium  on  Informa- 
tics in  Structural  Engineering  (Zurich;  Int.  Assoc,  of  Bridge  and 
Str.  Eng.,  1983),  pp.  301-316. 

A svunmary  of  work  up  to  1983. 

[30]  Howard,  H.  C.  and  S.  J.  Fenves,  "Representation  and  Comparison  of 
Design  Specifications,"  Report  R-83-141,  Department  of  Civil  Engi- 
neering (Pittsburgh:  Carnegie -Mellon  University,  1983). 

Extension  of  previous  work  to  the  comparison  and  representation  of 
similarities  and  differences  between  individual  design  specifica- 
tions . 

[31]  Stahl,  F.  I.,  R.  N.  Wright,  S.  J.  Fenves,  and  J.  R.  Harris, 
"Expressing  Standards  for  Computer-aided  Building  Design,"  Computer 
Aided  Design.  Vol.  15,  No.  6 (London:  Butterworth  and  Co.,  1983), 
pp.  329-334. 

A summary  of  the  SASE  methodology  and  program. 

[32]  Rudnicki,  R.  , "Decision  Table  Based  Software  for  Designing  with 

Standards,"  Unpublished  M.S.  Thesis  (Pittsburgh:  Carnegie -Mellon 

University,  1984) . 

A Pascal  program  that  generates  decision  trees  from  decision  tables 
and  inserts  condition  and  action  stubs  to  produce  a compilable 
Pascal  procedure  for  each  decision  table. 

[33]  Lopez,  L.  A.,  S.  L.  Elam  and  R.  N.  Wright,  Mapping  Principles  for 
the  Standards  Interface  for  Computer  Aided  Design.  NBSIR  85-3115 
(Gaithersburg;  National  Bureau  of  Standards,  1985). 
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Defines  the  data  interface  requirements  between  SASE  representa- 
tions of  standards  and  applications  programs. 

Worthington,  L.  A.  , "An  Interactive  Program  to  Assist  in  the 
Compilation  and  Checking  of  Specification  Provisions  in  Decision 
Table  Format,"  Unpublished  M.S.  Thesis  (Pittsburgh:  Carnegie-Mellon 
University,  1985). 

A Pascal  program  to  complete  an  intitially  sparse  decision  table 
and  make  various  checks  on  completeness  of  the  table. 

Slava,  M.  T. , "Structure  and  Organization  of  Project  Specifica- 
tions, " Unpublished  M.S.  Thesis  (Pittsburgh:  Carnegie-Mellon 
University,  1985). 

Extension  of  the  methodology  of  [13]  to  project  specifications. 

Fenves,  S.  J.,  and  J.  H.  Garrett,  Jr.,  "Standards  Representation 
and  Processing,"  in  Proceedings  of  lABSE  Symposium  on  Steel  in 
Buildings  (Zurich:  Int.  Assoc,  of  Bridge  and  Str.  Eng.,  1985),  pp , 
107-114. 

An  Updated  version  of  [29]. 

Fenves,  S.  J.,  and  J.  H.  Garrett,  Jr.,  "Knowledge -Based  Standards 
Processing,"  Int.  Journal  of  Artificial  Intellisence  in  Engineer- 
ing. Vol.  1,  No.  1 (London:  Computational  Mechanics  Publications, 
April  1986),  pp . 3-14. 

A model  of  a knowledge -based  system  which  uses  the  representational 
model  of  a specification  to  design  structural  components. 

Garrett,  J.  H. , Jr.  and  S.  J.  Fenves,  "A  Knowledge-Based  Standards 
Processor  for  Structural  Component  Design,"  Report  R-86-157, 
Department  of  Civil  Engineering  (Pittsburgh:  Carnegie-Mellon 
University,  1986). 

A specif ication- independent  knowledge -based  system  for  the  design 
of  structural  components.  The  designer  inputs  a hypothesis  identi- 
fying the  controlling  behavior.  The  system  translates  the  hypothe- 
sis into  appropriate  specification  provisions,  constructs  the 
resulting  constraints,  and  solves  for  the  basic  data  by  optimiza- 
tion or  database  lookup.  The  remaining  applicable  specification 
provisions  are  checked.  If  some  of  the  provisions  are  violated,  the 
system  backtracks  with  a new  hypothesis. 

Garrett,  J.  H. , Jr.  and  S.  J.  Fenves,  "A  Knowledge -Based  Standards 
Processor  for  Structural  Component  Design,"  to  appear  in  Engineer- 
ing with  Computers  (New  York:  Springer-Verlag , 1986). 


A summary  of  [37]. 


[40] 


Fenves , S.J.,  M.  T.  Slava  and  J.  P.  Barnett,  SASS  - 'Standards 
Analysis.  Synthesis,  and  Expression  Program:  User  Manual.  NBSIR  87- 
3514  (Gaithersburg:  National  Bureau  of  Standards,  1987). 

A detailed,  conunand-by- command  description  of  the  SASE  program. 

[41]  Lopez,  L.  A.  and  S.  Elam,  SICAD  User's  Manual.  NBS  GCR-87-531 
(Gaithersburg:  National  Bureau  of  Standards,  1987). 

A detailed  description  of  the  SICAD  (standards  interface  for 
computer  aided  design.)  programming  environment  developed  as  a 
support  tool  for  research  on  the  interface  [33]  between  standards 
and  computer  aided  design  systems.  The  system  supports  automatic 
checking  of  a design  for  conformance  with  applicable  provisions  of 
a standard  expressed  in  an  augmented  form  of  the  SASE  model. 
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manipulating  hierarchical  trees  of  classifiers  and  testing  the 
resulting  organization  for  completeness  and  clarity.  Entities  in 
SASE  that  deal  with  the  organization  of  a standard  are  class 
hierarchy,  scopelist,  index,  organization,  and  outline.  The  SASE 
methodology  is  demonstrated  in  an  analysis  of  a complete  standard 
for  concrete  quality.  An  Annotated  bibliography  of  the  most 
significant  relevant  research  reports  is  presented. 


